-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
correctly deal with unsorted generic parameters #74676
Conversation
@bors rollup=never I believe bors doesn't listen to commands in the descriptions of PRs. |
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit 9910f15 with merge ba1527a7e6cf83998280da8ed6fb2d5c16c77dda... |
☀️ Try build successful - checks-actions, checks-azure |
Queued ba1527a7e6cf83998280da8ed6fb2d5c16c77dda with parent 2bbfa02, future comparison URL. |
Finished benchmarking try commit (ba1527a7e6cf83998280da8ed6fb2d5c16c77dda): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Thanks for figuring out what was going on here — it's been a longstanding annoyance! @bors r+ |
📌 Commit 5f1eea9 has been approved by |
☀️ Test successful - checks-actions, checks-azure |
Remove restriction on type parameters preceding consts w/ feature const-generics Removed the restriction on type parameters preceding const parameters when the feature const-generics is enabled. Builds on rust-lang#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
We now stop sorting generic params and instead correctly handle unsorted params in the rest of the compiler.
We still restrict const params to come after type params though, so this PR does not change anything which
is visible to users.
This might slightly influence perf, so let's prevent any unintentional rollups. @bors rollup=never
r? @varkor