mirror of
https://github.com/rust-lang/rust-analyzer.git
synced 2026-03-24 20:40:30 +00:00
Auto merge of #151864 - aerooneqq:delegation-generics-propagation, r=petrochenkov
Implement AST -> HIR generics propagation in delegation This PR adds support for generics propagation during AST -> HIR lowering and is a part of rust-lang/rust#118212. # High-level design overview ## Motivation The task is to generate generics for delegations (i.e. in this context we assume a function that is created for `reuse` statements) during AST -> HIR lowering. Then we want to propagate those generated params to generated method call (or default call) in delegation. This will help to solve issues like the following: ```rust mod to_reuse { pub fn consts<const N: i32>() -> i32 { N } } reuse to_reuse::consts; //~^ ERROR type annotations needed // DESUGARED CURRENT: #[attr = Inline(Hint)] fn consts() -> _ { to_reuse::consts() } // DESUGARED DESIRED: #[attr = Inline(Hint)] fn consts<const N: i32>() -> _ { to_reuse::consts::<N>() } ``` Moreover, user can specify generic args in `reuse`, we need to propagate them (works now) and inherit signature with substituted generic args: ```rust mod to_reuse { pub fn foo<T>(t: T) -> i32 { 0 } } reuse to_reuse::foo::<i32>; //~^ ERROR mismatched types fn main() { foo(123); } error[E0308]: mismatched types --> src/main.rs:24:17 | 19 | pub fn foo<T>(t: T) -> i32 { | - found this type parameter ... 24 | reuse to_reuse::foo::<i32>; | ^^^ | | | expected `i32`, found type parameter `T` | arguments to this function are incorrect | = note: expected type `i32` found type parameter `T` ``` In this case we want the delegation to have signature that have one `i32` parameter (not `T` parameter). Considering all other cases, for now we want to preserve existing behavior, which was almost fully done (at this stage there are changes in behavior of delegations with placeholders and late-bound lifetimes). ## Main approach overview The main approach is as follows: - We determine generic params of delegee parent (now only trait can act as a parent as delegation to inherent impls is not yet supported) and delegee function, - Based on presence of user-specified args in `reuse` statement (i.e. `reuse Trait::<'static, i32, 123>::foo::<String>`) we either generate delegee generic params or not. If not, then we should include user-specified generic args into the signature of delegation, - The general order of generic params generation is as following: `[DELEGEE PARENT LIFETIMES, DELEGEE LIFETIMES, DELEGEE PARENT TYPES AND CONSTS, DELEGEE TYPES AND CONSTS]`, - There are two possible generic params orderings (they differ only in a position of `Self` generic param): - When Self is after lifetimes, this happens only in free to trait delegation scenario, as we need to generate implicit Self param of the delegee trait, - When Self is in the beginning and we should not generate Self param, this is basically all other cases if there is an implicit Self generic param in delegation parent. - Considering propagation, we do not propagate lifetimes for child, as at AST -> HIR lowering stage we can not know whether the lifetime is late-bound or early bound, so for now we do not propagate them at all. There is one more hack with child lifetimes, for the same reason we create predicates of kind `'a: 'a` in order to preserve all lifetimes in HIR, so for now we can generate more lifetimes params then needed. This will be partially fixed in one of next pull requests. ## Implementation details - We obtain AST generics either from AST of a current crate if delegee is local or from external crate through `generics_of` of `tcx`. Next, as we want to generate new generic params we generate new node ids for them, remove default types and then invoke already existent routine for lowering AST generic params into HIR, - If there are user-specified args in either parent or child parts of the path, we save HIR ids of those segments and pass them to `hir_analysis` part, where user-specified args are obtained, then lowered through existing API and then used during signature and predicates inheritance, - If there are no user-specified args then we propagate generic args that correspond to generic params during generation of delegation, - During signature inheritance we know whether parent or child generic args were specified by the user, if so, we should merge them with generic params (i.e. cases when parent args are specified and child args are not: `reuse Trait::<String>::foo`), next we use those generic args and mapping for delegee parent and child generic params into those args in order to fold delegee signature and delegee predicates. ## Tests New tests were developed and can be found in `ast-hir-engine` folder, those tests cover all cases of delegation with different number of lifetimes, types, consts in generic params and different user-specified args cases (parent and child, parent/child only, none). ## Edge cases There are some edge cases worth mentioning. ### Free to trait delegation. Consider this example: ```rust trait Trait<'a, T, const N: usize> { fn foo<'x: 'x, A, B>(&self) {} } reuse Trait::foo; ``` As we are reusing from trait and delegee has `&self` param it means that delegation must have `Self` generic param: ```rust fn foo<'a, 'x, Self, T, const N: usize, A, B>(self) {} ``` We inherit predicates from Self implicit generic param in `Trait`, thus we can pass to delegation anything that implements this trait. Now, consider the case when user explicitly specifies parent generic args. ```rust reuse Trait::<'static, String, 1>::foo; ``` In this case we do not need to generate parent generic params, but we still need to generate `Self` in delegation (`DelegationGenerics::SelfAndUserSpecified` variant): ```rust fn foo<'x, Self, A, B>(self) {} ``` User-specified generic arguments should be used to replace parent generic params in delegation, so if we had param of type `T` in `foo`, during signature inheritance we should replace it with user-specified `String` type. ### impl trait delegation When we delegate from impl trait to something, we want the delegation to have signature that matches signature in trait. For this reason we already resolve delegation not to the actual delegee but to the trait method in order to inherit its signature. That is why when processing user-specified args when the caller kind is `impl trait` (`FnKind::AssocTraitImpl`), we discard parent user-specified args and replace them with those that are specified in trait header. In future we will also discard `child_args` but we need proper error handling for this case, so it will be addressed in one of future pull requests that are approximately specified in "Nearest future work" section. ## Nearest future work (approximate future pull requests): - Late-bound lifetimes - `impl Trait` params in functions - Proper propagation of parent generics when generating method call - ~Fix diagnostics duplication during lowering of user-specified types~ - Support for recursive delegations - Self types support `reuse <u8 as Trait<_>>::foo as generic_arguments2` - Decide what to do with infer args `reuse Trait::<_, _>::foo::<_>` - Proper error handling when there is a mismatch between actual and expected args (impl trait case) r? @petrochenkov
This commit is contained in: