builtin object candidates: ReplaceProjectionWith relate failures
#171
Assignees
Comments
|
Above example shouldn't ICE if we don't walk into the trait Other<X> {}
trait Foo<T: Foo<T>>: Other<<T as Foo<T>>::Assoc> {
type Assoc;
}
impl<T> Foo<T> for T {
type Assoc = ();
}
impl<T: ?Sized> Other<()> for T {}
fn is_foo<T: Foo<()> + ?Sized>() {}
fn main() {
is_foo::<dyn Foo<(), Assoc = ()>>();
}It should be sufficient just to check that the self type of the projection to be replaced is |
|
A more interesting example that shows that we can't just use structural relation: trait Other<T> {}
impl<T> Other<T> for T {}
trait Super<T> {
type Assoc;
}
trait Mirror {
type Assoc;
}
impl<T> Mirror for T {
type Assoc = T;
}
trait Foo<A, B>: Super<<A as Mirror>::Assoc, Assoc = A> {
type FooAssoc: Other<<Self as Super<<A as Mirror>::Assoc>>::Assoc>;
}
fn is_foo<T, U>(x: &(impl Foo<T, U> + ?Sized)) {}
fn test(x: &dyn Foo<i32, u32, FooAssoc = i32>) {
is_foo::<i32, u32>(x);
}
fn main() {}b/c we'll need to emit |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Apr 17, 2025
…r=lcnr Fix replacing supertrait aliases in `ReplaceProjectionWith` The new solver has a procedure called `predicates_for_object_candidate`, which elaborates the super-bounds and item-bounds that are required to hold for a dyn trait to implement something via a built-in object impl. In that procedure, there is a folder called `ReplaceProjectionWith` which is responsible for replacing projections that reference `Self`, so that we don't encounter cycles when we then go on to normalize those projections in the process of proving these super-bounds. That folder had a few problems: Firstly, it wasn't actually checking that this was a super bound originating from `Self`. Secondly, it only accounted for a *single* projection type def id, but trait objects can have multiple (i.e. `trait Foo<A, B>: Bar<A, Assoc = A> + Bar<B, Assoc = B>`). To fix the first, it's simple enough to just add an equality check for the self ty. To fix the second, I implemented a matching step that's very similar to the `projection_may_match` check we have for upcasting, since on top of having multiple choices, we need to deal with both non-structural matches and ambiguity. This probably lacks a bit of documentation, but I think it works pretty well. Fixes rust-lang/trait-system-refactor-initiative#171 r? lcnr
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Apr 17, 2025
…r=lcnr Fix replacing supertrait aliases in `ReplaceProjectionWith` The new solver has a procedure called `predicates_for_object_candidate`, which elaborates the super-bounds and item-bounds that are required to hold for a dyn trait to implement something via a built-in object impl. In that procedure, there is a folder called `ReplaceProjectionWith` which is responsible for replacing projections that reference `Self`, so that we don't encounter cycles when we then go on to normalize those projections in the process of proving these super-bounds. That folder had a few problems: Firstly, it wasn't actually checking that this was a super bound originating from `Self`. Secondly, it only accounted for a *single* projection type def id, but trait objects can have multiple (i.e. `trait Foo<A, B>: Bar<A, Assoc = A> + Bar<B, Assoc = B>`). To fix the first, it's simple enough to just add an equality check for the self ty. To fix the second, I implemented a matching step that's very similar to the `projection_may_match` check we have for upcasting, since on top of having multiple choices, we need to deal with both non-structural matches and ambiguity. This probably lacks a bit of documentation, but I think it works pretty well. Fixes rust-lang/trait-system-refactor-initiative#171 r? lcnr
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Apr 17, 2025
…r=lcnr Fix replacing supertrait aliases in `ReplaceProjectionWith` The new solver has a procedure called `predicates_for_object_candidate`, which elaborates the super-bounds and item-bounds that are required to hold for a dyn trait to implement something via a built-in object impl. In that procedure, there is a folder called `ReplaceProjectionWith` which is responsible for replacing projections that reference `Self`, so that we don't encounter cycles when we then go on to normalize those projections in the process of proving these super-bounds. That folder had a few problems: Firstly, it wasn't actually checking that this was a super bound originating from `Self`. Secondly, it only accounted for a *single* projection type def id, but trait objects can have multiple (i.e. `trait Foo<A, B>: Bar<A, Assoc = A> + Bar<B, Assoc = B>`). To fix the first, it's simple enough to just add an equality check for the self ty. To fix the second, I implemented a matching step that's very similar to the `projection_may_match` check we have for upcasting, since on top of having multiple choices, we need to deal with both non-structural matches and ambiguity. This probably lacks a bit of documentation, but I think it works pretty well. Fixes rust-lang/trait-system-refactor-initiative#171 r? lcnr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
encountered during try builds when compiling
wasmparser.compiles on stable, results in the following ICE with the new solver
The text was updated successfully, but these errors were encountered: