You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I removed the source paths because it's just the source file where I defined a node-inheriting class and used GDCLASS as usual, it's irrelevant.
My warning flags are just /W4, which is recommended for new projects (and I dont intend to reduce that level, that warning is useful in my project's code).
Setting the include directory as "system" will not work because this is a macro injecting code in the user's sources.
This seems easy to fix if you either comment these names (which all seems part of the macro) OR by using [[maybe_unnamed]] on them.
However, when trying to make a PR , I realized that file might be generated through scripts because of the weird formatting, in which case the issue should be fixed in that generator instead, but I'm not totally sure. If you tell me to just comment the names directly in that header, I'll make a quick PR, otherwise I dont feel confident in fixing this quickly and correctly myself (yet).
Notes:
I can see the same issue with the same build configurations (so same flags) when using v4.2.2 instead of v4.3-rc2 so it's not a regression
I understand that there is an ongoing effort to reduce the warnings coming from the library headers - however here it's coming from a macro which needs to be used in user's source code, which implies that it can never be hidden without the user having to deactivate the warning themselves. Because these warnings seems easy to fix specifically in that macro, I think it's worth fixing these as a separate issue from the other header-warnings issues.
Steps to reproduce
Just adding /W4 to GODOT_COMPILE_FLAGS at cmake configuration using Visual Studio 2022 and building the test/ project will reveal the issue (I did test that locally).
In general, in any user project building using msvc:
set warning level 4 (/W4) when compiling a source file
in that source file, use GDCLASS as expected, for example (from my project):
// ...
#include<godot_cpp/core/class_db.hpp>
#include<godot_cpp/classes/node.hpp>// ...class__symexport MEGAST_Driver
: public godot::Node
{
GDCLASS(MEGAST_Driver, godot::Node) // HERE THE WARNINGS ARE GENERATEDpublic:// ...
};
(__symexport does the dllimport/export dance, ignore that)
Minimal reproduction project
N/A
The text was updated successfully, but these errors were encountered:
This is a silly warning, but I think it'd be fine to remove the names from the unused arguments in the GDCLASS() macro.
However, when trying to make a PR , I realized that file might be generated through scripts because of the weird formatting, in which case the issue should be fixed in that generator instead, but I'm not totally sure. If you tell me to just comment the names directly in that header, I'll make a quick PR
The wrapped.hpp file is not created by the code generator, so this would just be a matter of making a PR that modifies that file.
Godot version
4.3-rc2 4.2.2
godot-cpp version
2bcc4bd23c4e6d7db1f7d5f68be9727ac920c70a
System information
Windows 11, AMD Ryzen 9 5900X, 96GB RAM
Issue description
In my project using
godot-cpp
, when I have a type using GDCLASS macro (from wrapped.hpp) I get (among other) the following warnings:I removed the source paths because it's just the source file where I defined a node-inheriting class and used
GDCLASS
as usual, it's irrelevant.My warning flags are just
/W4
, which is recommended for new projects (and I dont intend to reduce that level, that warning is useful in my project's code).Setting the include directory as "system" will not work because this is a macro injecting code in the user's sources.
This seems easy to fix if you either comment these names (which all seems part of the macro) OR by using
[[maybe_unnamed]]
on them.However, when trying to make a PR , I realized that file might be generated through scripts because of the weird formatting, in which case the issue should be fixed in that generator instead, but I'm not totally sure. If you tell me to just comment the names directly in that header, I'll make a quick PR, otherwise I dont feel confident in fixing this quickly and correctly myself (yet).
Notes:
Steps to reproduce
Just adding
/W4
toGODOT_COMPILE_FLAGS
at cmake configuration using Visual Studio 2022 and building thetest/
project will reveal the issue (I did test that locally).In general, in any user project building using msvc:
/W4
) when compiling a source fileGDCLASS
as expected, for example (from my project):(
__symexport
does the dllimport/export dance, ignore that)Minimal reproduction project
N/A
The text was updated successfully, but these errors were encountered: