commit | 5bd98e36bc2102643cc6a93c2b894dd6a74be1c2 | [log] [tgz] |
---|---|---|
author | bors <bors@rust-lang.org> | Mon Oct 03 12:13:25 2022 +0000 |
committer | bors <bors@rust-lang.org> | Mon Oct 03 12:13:25 2022 +0000 |
tree | 2bbea222fe65b3ca195f893999e70f3cf317582c | |
parent | f087ebe6e7c80da747ecd4d7e1673a27c6729d34 [diff] | |
parent | 7556f74b1691276d12e4cf96eb2df8f74836cdc1 [diff] |
Auto merge of #13335 - lowr:patch/change-generic-param-order, r=Veykril internal: change generic parameter order tl;dr: This PR changes the `Substitution` for trait items and methods like so: ```rust trait Trait<TP, const CP: usize> { // note the implicit Self as first parameter type Type<TC, const CC: usize>; fn f<TC, const CC: usize>() {} } impl<TP, const CP: usize> S { fn f<TC, const CC: usize>() {} } ``` - before this PR: `[Self, TP, CP, TC, CC]` for each trait item, `[TP, CP, TC, CC]` for `S::f` - after this PR: `[TC, CC, Self, TP, CP]` for each trait item, `[TC, CC, TP, CP]` for `S::f` --- This PR "inverts" the generic parameters/arguments of an item and its parent. This is to fulfill [chalk's expectation](https://github.com/rust-lang/chalk/blob/d875af0ff196dd6430b5f5fd87a640fa5ab59d1e/chalk-solve/src/rust_ir.rs#L498-L502) on the order of generic arguments in `Substitution`s for generic associated types and it's one step forward for GATs support (hopefully). Although chalk doesn't put any constraint for other items, it feels more natural to get everything aligned than special casing GATs. One complication is that `TyBuilder` now demands its users to pass in parent's `Substitution` upon construction unless it's obvious that the the item has no parent (e.g. an ADT never has parent). All users *should* already know the parent of the item in question, and without this, it cannot be easily reasoned about whether we're pushing the argument for the item or for its parent. Some additional notes: - f8f5a5ea5788a846013545d63c9b46fd70cc4f7c: This isn't related to the change, but I felt it's nicer. - 78977cd86cd17e008f94f8579d6a5aaebe46e69b: There's one major change here other than the generic param order: Default arguments are now bound by the same `Binder` as the item in question rather than a `Binder` limited to parameters they can refer to (i.e. arguments that syntactically appear before them). Now that the order of generic parameters is changed, it would be somewhat complicated to make such `Binder`s as before, and the "full" `Binder`s shouldn't be a problem because we already make sure that the default arguments don't refer to the generic arguments after them with `fallback_bound_vars()`. - 7556f74b1691276d12e4cf96eb2df8f74836cdc1: This is split from 4385d3dcd0df7713b3a35f31f11034f0a570adbd to make it easy to revert if it turns out that the GATs with const generics panic is actually not resolved with this PR. cc #11878 #11957
rust-analyzer is a modular compiler frontend for the Rust language. It is a part of a larger rls-2.0 effort to create excellent IDE support for Rust.
https://rust-analyzer.github.io/manual.html#installation
If you want to contribute to rust-analyzer or are just curious about how things work under the hood, check the ./docs/dev folder.
If you want to use rust-analyzer's language server with your editor of choice, check the manual folder. It also contains some tips & tricks to help you be more productive when using rust-analyzer.
See the corresponding sections of the manual.
For usage and troubleshooting requests, please use “IDEs and Editors” category of the Rust forum:
https://users.rust-lang.org/c/ide/14
For questions about development and implementation, join rust-analyzer working group on Zulip:
https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer
rust-analyzer is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.