(some older discussion here: https://hackmd.io/kw8vfb2oSFyQqatCjaFVSw)
Making objects' built-in bounds sound
when proving a predicate for dyn Trait from one of its existential bounds, we need to prove that all of the supertraits of that bound's trait hold for dyn Trait, plus all of the associated types' item bounds hold.
For example, given:
trait Trait {
type Assoc: Bound + ?Sized;
}
For dyn Trait<Assoc = i32>: Trait to be proven, we must check the item bounds on Assoc.
If we do no additional work on top of just calling tcx.item_bounds({Trait::Assoc def-id}) and substituting Self = dyn Trait<Assoc = i32>, we get <dyn Trait<Assoc = i32> as Trait>::Assoc: Bound. However, in the new solver, this goal holds trivially via an alias bound candidate from the associated type.
To fix this, rust-lang/rust#108333 folds these object bounds, eagerly replacing projections with the associated types' values that appear in the dyn Trait itself. This would give us i32: Bound, which would fail.
Is this sufficient?
Idk. We probably should find that out before stabilizing the new solver, though.
(some older discussion here: https://hackmd.io/kw8vfb2oSFyQqatCjaFVSw)
Making objects' built-in bounds sound
when proving a predicate for
dyn Traitfrom one of its existential bounds, we need to prove that all of the supertraits of that bound's trait hold fordyn Trait, plus all of the associated types' item bounds hold.For example, given:
For
dyn Trait<Assoc = i32>: Traitto be proven, we must check the item bounds onAssoc.If we do no additional work on top of just calling
tcx.item_bounds({Trait::Assoc def-id})and substitutingSelf = dyn Trait<Assoc = i32>, we get<dyn Trait<Assoc = i32> as Trait>::Assoc: Bound. However, in the new solver, this goal holds trivially via an alias bound candidate from the associated type.To fix this, rust-lang/rust#108333 folds these object bounds, eagerly replacing projections with the associated types' values that appear in the
dyn Traititself. This would give usi32: Bound, which would fail.Is this sufficient?
Idk. We probably should find that out before stabilizing the new solver, though.