Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Rollup merge of rust-lang#136458 - compiler-errors:fix-3, r=lcnr Do not deduplicate list of associated types provided by dyn principal ## Background The way that we handle a dyn trait type's projection bounds is very *structural* today. A dyn trait is represented as a list of `PolyExistentialPredicate`s, which in most cases will be a principal trait (like `Iterator`) and a list of projections (like `Item = u32`). Importantly, the list of projections comes from user-written associated type bounds on the type *and* from elaborating the projections from the principal's supertraits. For example, given a set of traits like: ```rust trait Foo<T> { type Assoc; } trait Bar<A, B>: Foo<A, Assoc = A> + Foo<B, Assoc = B> {} ``` For the type `dyn Bar<i32, u32>`, the list of projections will be something like `[Foo<i32>::Assoc = i32, Foo<u32>::Assoc = u32]`. We deduplicate these projections when they're identical, so for `dyn Bar<(), ()>` would be something like `[Foo<()>::Assoc = ()]`. ## Shortcomings 1: inference We face problems when we begin to mix this structural notion of projection bounds with inference and associated type normalization. For example, let's try calling a generic function that takes `dyn Bar<A, B>` with a value of type `dyn Bar<(), ()>`: ```rust trait Foo<T> { type Assoc; } trait Bar<A, B>: Foo<A, Assoc = A> + Foo<B, Assoc = B> {} fn call_bar<A, B>(_: &dyn Bar<A, B>) {} fn test(x: &dyn Bar<(), ()>) { call_bar(x); // ^ ERROR mismatched types } ``` ``` error[E0308]: mismatched types --> /home/mgx/test.rs:10:14 | 10 | call_bar(x); | -------- ^ expected trait `Bar<_, _>`, found trait `Bar<(), ()>` ``` What's going on here? Well, when calling `call_bar`, the generic signature `&dyn Bar<?A, ?B>` does not unify with `&dyn Bar<(), ()>` because the list of projections differ -- `[Foo<?A>::Assoc = ?A, Foo<?B>::Assoc = ?B]` vs `[Foo<()>::Assoc = ()]`. A simple solution to this may be to unify the principal traits first, then attempt to deduplicate them after inference. In this case, if we constrain `?A = ?B = ()`, then we would be able to deduplicate those projections in the first list. However, this idea is still pretty fragile, and it's not a complete solution. ## Shortcomings 2: normalization Consider a slightly modified example: ```rust //@ compile-flags: -Znext-solver trait Mirror { type Assoc; } impl<T> Mirror for T { type Assoc = T; } fn call_bar(_: &dyn Bar<(), <() as Mirror>::Assoc>) {} fn test(x: &dyn Bar<(), ()>) { call_bar(x); } ``` This fails in the new solver. In this example, we try to unify `dyn Bar<(), ()>` and `dyn Bar<(), <() as Mirror>::Assoc>`. We are faced with the same problem even though there are no inference variables, and making this work relies on eagerly and deeply normalizing all projections so that they can be structurally deduplicated. This is incompatible with how we handle associated types in the new trait solver, and while we could perhaps support it with some major gymnastics in the new solver, it suggests more fundamental shortcomings with how we deal with projection bounds in the new solver. ## Shortcomings 3: redundant projections Consider a final example: ```rust trait Foo { type Assoc; } trait Bar: Foo<Assoc = ()> {} fn call_bar1(_: &dyn Bar) {} fn call_bar2(_: &dyn Bar<Assoc = ()>) {} fn main() { let x: &dyn Bar<Assoc = _> = todo!(); call_bar1(x); //~^ ERROR mismatched types call_bar2(x); //~^ ERROR mismatched types } ``` In this case, we have a user-written associated type bound (`Assoc = _`) which overlaps the bound that comes from the supertrait projection of `Bar` (namely, `Foo<Assoc = ()>`). In a similar way to the two examples above, this causes us to have a projection list mismatch that the compiler is not able to deduplicate. ## Solution ### Do not deduplicate after elaborating projections when lowering `dyn` types The root cause of this issue has to do with mismatches of the deduplicated projection list before and after substitution or inference. This PR aims to avoid these issues by *never* deduplicating the projection list after elaborating the list of projections from the *identity* substituted principal trait ref. For example, ```rust trait Foo<T> { type Assoc; } trait Bar<A, B>: Foo<A, Assoc = A> + Foo<B, Assoc = B> {} ``` When computing the projections for `dyn Bar<(), ()>`, before this PR we'd elaborate `Bar<(), ()>` to find a (deduplicated) projection list of `[Foo<()>::Assoc = ()]`. After this PR, we take the principal trait and use its *identity* substitutions `Bar<A, B>` during elaboration, giving us projections `[Foo<A>::Assoc = A, Foo<B>::Assoc = B]`. Only after this elaboration do we substitute `A = (), B = ()` to get `[Foo<()>::Assoc = (), Foo<()>::Assoc = ()]`. This allows the type to be unified with the projections for `dyn Bar<?A, ?B>`, which are `[Foo<?A>::Assoc = ?A, Foo<?B>::Assoc = ?B]`. This helps us avoid shorcomings 1 noted above. ### Do not deduplicate projections when relating `dyn` types Similarly, we also do not call deduplicate when relating dyn types. This means that the list of projections does not differ depending on if the type has been normalized or not, which should avoid shortcomings 2 noted above. Following from the example above, when relating projection lists like `[Foo<()>::Assoc = (), Foo<()>::Assoc = ()]` and `[Foo<?A>::Assoc = ?A, Foo<?B>::Assoc = ?B]`, the latter won't be deduplicated to a list of length 1 which would immediately fail to relate to the latter which is a list of length 2. ### Implement proper precedence between supertrait and user-written projection bounds when lowering `dyn` types ```rust trait Foo { type Assoc; } trait Bar: Foo<Assoc = ()> {} ``` Given a type like `dyn Foo<Assoc = _>`, we used to previously include *both* the supertrait and user-written associated type bounds in the projection list, giving us `[Foo::Assoc = (), Foo::Assoc = _]`. This would never unify with `dyn Foo`. However, this PR implements a strategy which overwrites the supertrait associated type bound with the one provided by the user, giving us a projection list of `[Foo::Assoc = _]`. Why is this OK? Well, if a user wrote an associated type bound that is unsatisfiable (e.g. `dyn Bar<Assoc = i32>`) then the dyn type would never implement `Bar` or `Foo` anyways. If the user wrote something that is either structurally equal or equal modulo normalization to the supertrait bound, then it should be unaffected. And if the user wrote something that needs inference guidance (e.g. `dyn Bar<Assoc = _>`), then it'll be constrained when proving `dyn Bar<Assoc = _>: Bar`. Importantly, this differs from the strategy in rust-lang#133397, which preferred the *supertrait* bound and ignored the user-written bound. While that's also theoretically justifiable in its own way, it does lead to code which does not (and probably should not) compile either today or after this PR, like: ```rust trait IteratorOfUnit: Iterator<Item = ()> {} impl<T> IteratorOfUnit for T where T: Iterator<Item = ()> {} fn main() { let iter = [()].into_iter(); let iter: &dyn IteratorOfUnit<Item = i32> = &iter; } ``` ### Conclusion This is a far less invasive change compared to rust-lang#133397, and doesn't necessarily necessitate the addition of new lints or any breakage of existing code. While we could (and possibly should) eventually introduce lints to warn users of redundant or mismatched associated type bounds, we don't *need* to do so as part of fixing this unsoundness, which leads me to believe this is a much safer solution.
- Loading branch information
