Skip to content

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

Open
compiler-errors opened this issue Apr 18, 2025 · 4 comments
Assignees
Labels
from-crater A regression found via a crater run, not part of our test suite

Comments

@compiler-errors
Copy link
Member

compiler-errors commented Apr 18, 2025

https://crater-reports.s3.amazonaws.com/pr-133502-2/try%23da0a4799770027c4c578bf48cdb390acfde09023/reg/reblessive-0.4.3/log.txt

async fn mirror<T>(t: T) -> T {
    let x = Box::pin(mirror(String::new())).await;
    let recur = x.len();
    
    t
}

Recursive non-defining use. Old solver can solve {opaque#0}::<String>: Future<Output = ?x> and constrains the type of variable x.

@lcnr lcnr moved this to unknown in -Znext-solver=globally Apr 19, 2025
@lcnr lcnr changed the title reblessive regression reblessive regression: non universal non-defining opaque type use Apr 19, 2025
@lcnr lcnr added the from-crater A regression found via a crater run, not part of our test suite label Apr 19, 2025
@lcnr
Copy link
Contributor

lcnr commented Apr 24, 2025

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
}

@lcnr
Copy link
Contributor

lcnr commented Apr 24, 2025

and #135. From what I can tell reblessive only breaks due to this issue and does not have a non-universal use in the defining scope.

@lcnr lcnr changed the title reblessive regression: non universal non-defining opaque type use reblessive regression: rely on item bounds of not-yet-defined opaque types Apr 24, 2025
@compiler-errors
Copy link
Member Author

Another repro:

trait Test {
    type Output;
    fn method(self) -> Self::Output;
}
impl Test for () {
    type Output = Bar;
    fn method(self) -> Bar { Bar }
}

struct Bar;
impl Bar {
    fn bar(&self) {}
}

fn foo() -> impl Test<Output = Bar> {
    let x = Test::method(foo());
    x.bar();
}

Fixing this requires us to fix two independent issues:

  1. Opaques may only be related to the goal's self ty via subtyping. This requires us to canonicalize at least part of the subtyping graph.
  2. We get a cycle when (e.g.) equating the assumption impl Sized: Sized and the goal ?0: Sized, since that then subsequently requires proving ?0: Sized in the process of normalizing impl Sized to its hidden type ?0. We could get around this by folding the item bounds of the opaque.

@compiler-errors
Copy link
Member Author

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.

bors added a commit to rust-lang-ci/rust that referenced this issue Apr 28, 2025
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`
@lcnr lcnr moved this from unknown to in progress in -Znext-solver=globally Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
from-crater A regression found via a crater run, not part of our test suite
Projects
Status: in progress
Development

No branches or pull requests

2 participants