-
Notifications
You must be signed in to change notification settings - Fork 0
reblessive regression: rely on item bounds of not-yet-defined opaque types #182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The above issue contains two issues: Relying on inference guidance from item bounds of not yet inferred opaque types: trait Id {
type This;
}
impl<T> Id for T {
type This = T;
}
fn to_assoc<T>(x: T) -> <T as Id>::This {
x
}
fn mirror<T>(x: Vec<T>) -> impl Id<This = Vec<T>> {
let x = to_assoc(mirror(x));
// `?x` equals `<opaque::<T> as Id>::This`. As the hidden type of `opaque::<T>`
// is still unknown at this point, the method below.
x.len();
x
} |
and #135. From what I can tell |
Another repro:
Fixing this requires us to fix two independent issues:
|
We also probably should not equate the self type of the goal with the hidden type of the opaque. This probably necessitates folding the item bounds of the opaque like I mentioned in (2.) above. |
eagerly compute `sub_relations` again We still only using them for diagnostics with the old solver. We could use them for cycle detection in generalization and it seems desirable to do so in the future. However, this is unsound with the old trait solver as its cache does not track these `sub_relations` in any way. We would also need to consider them when canonicalizing as otherwise instantiating the canonical response may fail. Necessary for type inference guidance due to not-yet defined opaque types, cc rust-lang/trait-system-refactor-initiative#182. r? `@compiler-errors`
https://crater-reports.s3.amazonaws.com/pr-133502-2/try%23da0a4799770027c4c578bf48cdb390acfde09023/reg/reblessive-0.4.3/log.txt
Recursive non-defining use. Old solver can solve
{opaque#0}::<String>: Future<Output = ?x>
and constrains the type of variablex
.The text was updated successfully, but these errors were encountered: