-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[libc++] Support more GCC 15 type_traits builtins #137871
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
Open
frobtech
wants to merge
2
commits into
llvm:main
Choose a base branch
from
frobtech:p/libcxx-gcc15-type-traits
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+52
−0
Open
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
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
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.
We should just use
add_lvalue_reference
in the GCC branch in the end. I think it would be better to just disable this branch for the GCC upgrade and do a proper refactoring afterwards. You've probably just copy-pasted what I've done forremove_cvref
, but that's a bit special, since we've got an internal type trait for versions beforeremove_cvref
was added.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.
GCC 15 has only just been released and GCC 14 is still in wide use and does not have the builtin.
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 only support the latest version of GCC.
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.
If there is no window where both 14 and 15 work, then you make it impossible for people to upgrade. I need to upgrade to a fixed libc++ today so that I can upgrade to GCC 15 tomorrow. I can't upgrade to GCC 15 today because I need first land an upgraded libc++.
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.
That's been the policy for years and nobody had a problem with it. Also, this is not the PR to discuss policy changes. If you think we should change our support policy feel free to write an RFC.
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.
I'm trying to understand your interpretation of the policy. In #81386 you made a change that made libc++ work with both GCC 14 (the latest release branch at the time) and with GCC 15, which was unreleased and not a stable branch at the time. So by the policy, that change should not have gone in because only 14 was supported then.
Now, on the day that GCC 15 is released, the policy becomes that only 15 is supported and 14 is no longer supported. But the reality on that day was that 15 did not work and 14 did. By a straightforward and consistent interpretation of the policy, #81386 should not have gone in. By the same policy, at the instant of the GCC 15 release, 15 was the sole supported version--but it was broken, making it impossible for anyone using libc++ to switch to 15 on that day.
AFAICT the policy as written is obviously unworkable because as of today, the time window of GCC support is 5 days. AFAICT the policy as written also applies to me but not to you.
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.
I'm not saying you should break GCC 14 with this patch. I'm saying you ahould just disable the problematic branches, and after we upgrade the CI to 15 we'll clean it up.