Skip to content
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

Merged
merged 9 commits into from
Aug 10, 2020

Conversation

JulianKnodt
Copy link
Contributor

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

@rust-highfive
Copy link
Collaborator

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.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 30, 2020
Copy link
Contributor

@lcnr lcnr left a 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);

src/test/ui/const-generics/defaults/right-order.rs Outdated Show resolved Hide resolved
src/test/ui/const-generics/defaults/needs-feature.rs Outdated Show resolved Hide resolved
@lcnr
Copy link
Contributor

lcnr commented Jul 30, 2020

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 feature(const_generics) and keep disallowing this when using feature(min_const_generics)?

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.

@JulianKnodt
Copy link
Contributor Author

JulianKnodt commented Aug 5, 2020

Woops accidentally closed this while trying to revert some accidental merges

@JulianKnodt
Copy link
Contributor Author

@bors try

@bors
Copy link
Contributor

bors commented Aug 6, 2020

@JulianKnodt: 🔑 Insufficient privileges: not in try users

@JulianKnodt
Copy link
Contributor Author

Hm it works locally with these changes

@bors
Copy link
Contributor

bors commented Aug 8, 2020

☔ The latest upstream changes (presumably #74877) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Contributor

@lcnr lcnr left a 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/librustc_ast/ast.rs Outdated Show resolved Hide resolved
src/librustc_ast/ast.rs Outdated Show resolved Hide resolved
src/librustc_ast/ast.rs Outdated Show resolved Hide resolved
src/test/ui/const-generics/defaults/complex-unord-param.rs Outdated Show resolved Hide resolved
src/test/ui/const-generics/defaults/right-order.rs Outdated Show resolved Hide resolved
src/librustc_ast/ast.rs Outdated Show resolved Hide resolved
src/test/ui/const-generics/defaults/needs-feature.rs Outdated Show resolved Hide resolved
src/librustc_ast/ast.rs Outdated Show resolved Hide resolved
src/librustc_ast/ast.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
@lcnr
Copy link
Contributor

lcnr commented Aug 10, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Aug 10, 2020

📌 Commit 64f6437 has been approved by lcnr

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 10, 2020
@bors
Copy link
Contributor

bors commented Aug 10, 2020

⌛ Testing commit 64f6437 with merge 04f5cefa734a20bd5edb13d43c0322720ac7174f...

@bors
Copy link
Contributor

bors commented Aug 10, 2020

💥 Test timed out

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 10, 2020
@lcnr
Copy link
Contributor

lcnr commented Aug 10, 2020

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 10, 2020
@bors
Copy link
Contributor

bors commented Aug 10, 2020

⌛ Testing commit 64f6437 with merge 08324fe...

@bors
Copy link
Contributor

bors commented Aug 10, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: lcnr
Pushing 08324fe to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 10, 2020
@bors bors merged commit 08324fe into rust-lang:master Aug 10, 2020
@varkor varkor added the F-const_generics `#![feature(const_generics)]` label Aug 12, 2020
Copy link
Member

@varkor varkor left a 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>`
Copy link
Member

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"
Copy link
Member

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"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ups

Copy link
Contributor

@lcnr lcnr Aug 12, 2020

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

@varkor
Copy link
Member

varkor commented Aug 12, 2020

Sorry, I didn't have time to get to this before now.

@lcnr
Copy link
Contributor

lcnr commented Aug 12, 2020

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.

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.
(https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=06b9ccfc5d0c7ba4fd610635eda2179a)

Lifting the ordering restriction on lt bounds would also require an RFC, wouldn't it?

@varkor
Copy link
Member

varkor commented Aug 12, 2020

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 lifetimes, types, consts, type defaults, const defaults as a strict order.

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Aug 13, 2020
Flip order of const & type

Fix swapped order of consts & types in error message introduced in rust-lang#74953

r? @varkor cc @lcnr
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-const_generics `#![feature(const_generics)]` merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants