-
Notifications
You must be signed in to change notification settings - Fork 294
[General] Fixing sparse bugs #14247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
[General] Fixing sparse bugs #14247
Changes from 4 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
82cac39
Using explicit types
roigcarlo 04b5737
Semicolon
roigcarlo 7684188
Using Correct datatypes
roigcarlo 2a7972c
Missing serializer
roigcarlo 1c25685
Replace include by explicit forward declaration
roigcarlo d2b160b
Wrong copypaste
roigcarlo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @roigcarlo,
I have to admit that I don't see why it would be required to have this include here. Class
Serializeris forward-declared and the only usages in this header file are references to this class (which is sufficient information for the compiler at this point). The implementation file (tension_cutoff.cpp) does have the include that you've added here now, which makes sense, since there we actually do something with the serializer objects.The other thing that confuses me is that all other builds on GitHub pass with the status quo (i.e. without the additional include). So I'm wondering whether there is anything special about the build configuration that you're trying? Or perhaps there's something else that I overlook? If you have any ideas, please let me know. Thanks.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @avdg81, that drove me crazy a little bit as well. This is what I think is happening:
In the case of the CI is never a problem because it uses unitary builds which in practice is like having a PCH on windows, so the
serializer.hinclude may come from the stack of headers included in the other sources (unlesstension_cutoff.cppis the first source bundled)The second problem is more subtle. I am not 100% sure about if this is the case, but is the only think I came up with after searching for a while: I assume that the intention is for the
friend class Serializerto also act as implicit forward declaration, but that declaration exists inside a class inside thenamespace Kratos, so while it is true thatSerializeris implicitly declared asKratos::Serializerit is not as::Serializerso it is not in the global lookup namespace. Seems that MSVC and some versions of gcc/clang simply do not enforce this rule and allow the declaration to be seen so that would explain why it does not normally fails. As a matter of fact, this specific header compiled well for the windows release, it only failed in GCC 14.P.s.
This is the rule that should fr followed by the compiler but is being ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @roigcarlo,
Thanks a lot for investigating my question. Perhaps then the better way to solve it is to have a forward declaration in the
Kratosnamespace and use a friend declaration like this:friend Serializer;(or should it befriend Kratos::Serializer;?). My point is: if we can use a forward declaration (and I think we can), then I would prefer that over an extra include. May I ask you to try this for me? Thanks. If it works, I'm happy to make this change myself using a new PR, since we have similar constructs in other classes, too.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@avdg81 Np,
This pretty much solves the problem as well. 👍