@@ -219,7 +219,7 @@ impl<'t, I: Interner> Unifier<'t, I> {
219219 }
220220 self . zip_substs (
221221 variance,
222- None ,
222+ None , // TODO: AssociatedType variances?
223223 substitution_a. as_slice ( interner) ,
224224 substitution_b. as_slice ( interner) ,
225225 )
@@ -790,13 +790,17 @@ impl<'t, I: Interner> Unifier<'t, I> {
790790 // too much onto `var`. Instead of directly setting `var` equal to `ty`,
791791 // we just take the outermost structure we _know_ `var` holds, and then
792792 // apply that to `ty`. This involves creating new inference vars for
793- // everything inside `var`, then recursing down to unify those new
794- // inference variables with
795-
796- // TODO: the justification for why we need to generalize here is a bit
797- // weak. Could we include a concrete example of what this fixes? Or,
798- // alternatively, link to a test case which requires this & say "it's
799- // complicated why exactly we need this".
793+ // everything inside `var`, then calling `relate_ty_ty` to relate those
794+ // inference vars to the things they generalized with the correct
795+ // variance.
796+
797+ // The main problem this solves is that lifetime relationships are
798+ // relationships, not just eq ones. So when solving &'a u32 <: U,
799+ // generalizing we would end up with U = &'a u32. Instead, we want
800+ // U = &'b u32, with a lifetime constraint 'a <: 'b. This matters
801+ // especially when solving multiple constraints - for example, &'a u32
802+ // <: U, &'b u32 <: U (where without generalizing, we'd end up with 'a
803+ // <: 'b, where we really want 'a <: 'c, 'b <: 'c for some 'c).
800804
801805 // Example operation: consider `ty` as `&'x SomeType`. To generalize
802806 // this, we create two new vars `'0` and `1`. Then we relate `var` with
0 commit comments