-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[Clang] Fix __is_trivially_equality_comparable returning true with ineligebile defaulted overloads #93113
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
philnik777
merged 1 commit into
llvm:main
from
philnik777:fix_is_trivially_equality_comparable
Jun 27, 2024
Merged
[Clang] Fix __is_trivially_equality_comparable returning true with ineligebile defaulted overloads #93113
Changes from all commits
Commits
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
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
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.
It's unfortunate that the other traits are implemented directly on
Type
but this one is in SemaExprCXX.cpp and isn't possible to compute without access toSema
. ISTM we should be able to answer this question on the type rather than requiring semantic analysis (considering potential uses like in clang-tidy where there is noSema
available).Perhaps another way to approach this is with the
DefinitionData
for classes -- as we add members to the class, we build up information about whether something is trivially copyable, etc and store that on the bits defined inCXXRecordDeclDefinitionBits.def
. Maybe we could do the same for equality comparable types, then we can leave this interface inType
and do special handling if the type is aCXXRecordDecl
. WDYT?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.
The main problem with this is that you don't have to have a member. Take this test case for example:
I'm sure this can also be written with some
requires
clause. Without the builtin telling the library there is no way to figure out that a free function instead of the member is called.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.
Well shoot! That's... frustrating. What about splitting the logic between
Type
andSema
? e.g.,Type
tracks whether the type in isolation is trivially equality comparable, andSema
can use that to early return if a type is not trivially equality comparable in isolation and do additional semantic checking otherwise to provide the value for the trait.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.
We're not actually storing any infomation for
__is_trivially_equaltiy_comparable
, so I'm not sure what the benefit would be? If we ever do that we can of course split things up to say "this definitely isn't trivially equaility comparable".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.
Yeah, it's not that we already have this information, it's a different approach to your current patch so that the functionality continues to live on
Type
(the benefit is that external consumers like downstreams or clang-tidy could continue to use the same interface they always have but get slightly more accurate results from it). If that is more effort than it's worth, I don't insist -- I'm not aware of any breakage from your current changes.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.
Hmm. I'm not sure the is much use to "this is definitely not trivially equality comparable". Right now I think I'd rather just keep it in
SemaExprCXX
. If there comes up a use-case or we want to save some of the information we can still move some info intoType
.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.
Okay, I'm sold. Thanks for entertaining the idea!
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.
Always happy to do that!