-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Remove restriction on type parameters preceding consts w/ feature const-generics #74953
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @lcnr (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
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.
Nice to see that this already works!
The way ParamKindOrd
works rn is somewhat unfortunate, I think either adding a field to ParamKindOrd::Const(bool)
to specify if const_generics
is active or adding a new ParamKindOrd::MinConst
variant is the best way to fix this for now.
For example I would expect the following to still result in an incorrect help message.
struct Foo<const N: usize, 'a, T = u32>(&'a (), T);
cc @varkor @withoutboats @eddyb The goal of this PR is to remove the restriction on the param ordering between types and consts to allow for type defaults. Should we only lift that restriction when using As you can see from this PR, keeping that restriction doesn't simplify the implementation. So keeping that restriction would mostly allow us keep forcing that parameter order in the future. I personally am unsure how else we might want to implement default parameters here, so I would be fine with also allowing this as part of of the MVP. |
Woops accidentally closed this while trying to revert some accidental merges |
@bors try |
@JulianKnodt: 🔑 Insufficient privileges: not in try users |
Hm it works locally with these changes |
☔ The latest upstream changes (presumably #74877) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
A lot of small nits, once these are fixed r=me.
src/test/ui/const-generics/defaults/type-after-const-requires-default.rs
Outdated
Show resolved
Hide resolved
Added this test to ensure that reordering the parameters only works with the feature const generics enabled. Fixed nits Also added another test to verify that intermixed lifetimes are forbidden
Added more complex test and changed error message
Added minor fmt change to ast_validation
Updated tests and error msgs Update stderr from test Update w/ lcnr comments Change some tests around, and also updated Ord implementation for ParamKindOrd Update w/ nits from lcnr
@bors r+ |
📌 Commit 64f6437 has been approved by |
⌛ Testing commit 64f6437 with merge 04f5cefa734a20bd5edb13d43c0322720ac7174f... |
💥 Test timed out |
@bors retry |
☀️ Test successful - checks-actions, checks-azure |
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.
What's the reason we only allow consts and types to be reordered? If we're lifting the arbitrary restriction, we may as well lift it entirely.
--> $DIR/needs-feature.rs:10:26 | ||
| | ||
LL | struct A<const N: usize, T=u32>(T); | ||
| -----------------^----- help: reorder the parameters: lifetimes, then consts, then types: `<T, const N: usize>` |
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.
This error message is wrong.
if sess.features_untracked().const_generics { | ||
", then consts and types" | ||
} else if sess.features_untracked().min_const_generics { | ||
", then consts, then types" |
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.
Shouldn't this be ", then types, then consts"
?
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.
ups
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.
@JulianKnodt do you want to open a PR for this? Otherwise I will quickly fix that
Sorry, I didn't have time to get to this before now. |
mixing lt with types was forbidden before 😆 I do feel like const and type parameters are more similar than lt params. We also can't specify late bound lt params, which makes mixing them with other parameters somewhat undesirable imo. Lifting the ordering restriction on lt bounds would also require an RFC, wouldn't it? |
Really, lifting the restriction even for normal const generics ought to require some discussion, as it wasn't part of the original RFC. I think if we're restricting at all, it makes sense to have |
Flip order of const & type Fix swapped order of consts & types in error message introduced in rust-lang#74953 r? @varkor cc @lcnr
Removed the restriction on type parameters preceding const parameters when the feature const-generics is enabled.
Builds on #74676, which deals with unsorted generic parameters. This just lifts the check in lowering the AST to HIR that permits consts and types to be reordered with respect to each other. Lifetimes still must precede both
This change is not intended for min-const-generics, and is gated behind the
#![feature(const_generics)]
.One thing is that it also permits type parameters without a default to come after consts, which I expected to not work, and was hoping to get more guidance on whether that should be permitted or how to prevent it otherwise.
I did not go through the RFC process for this pull request because there was prior work to get this feature added. In the previous PR that was cited, work was done to enable this change.
r? @lcnr