Skip to content

reblessive regression: rely on item bounds of not-yet-defined opaque types  #182

Open
rust-lang/rust
#140405
@compiler-errors

Description

@compiler-errors
Member

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.

Activity

changed the title [-]reblessive regression[/-] [+]reblessive regression: non universal non-defining opaque type use[/+] on Apr 19, 2025
added
from-craterA regression found via a crater run, not part of our test suite
on Apr 19, 2025
lcnr

lcnr commented on Apr 24, 2025

@lcnr
Contributor

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

lcnr commented on Apr 24, 2025

@lcnr
Contributor

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.

changed the title [-]reblessive regression: non universal non-defining opaque type use[/-] [+]reblessive regression: rely on item bounds of not-yet-defined opaque types [/+] on Apr 24, 2025
compiler-errors

compiler-errors commented on Apr 25, 2025

@compiler-errors
MemberAuthor

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

compiler-errors commented on Apr 25, 2025

@compiler-errors
MemberAuthor

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.

added a commit that references this issue on Apr 28, 2025

Auto merge of rust-lang#140375 - lcnr:subrelations-infcx, r=<try>

moved this from unknown to in progress in -Znext-solver=globallyon Apr 28, 2025
added a commit that references this issue on Apr 29, 2025

Auto merge of rust-lang#140375 - lcnr:subrelations-infcx, r=<try>

4 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

from-craterA regression found via a crater run, not part of our test suite

Type

No type

Projects

Status

in progress

Milestone

No milestone

Relationships

None yet

    Participants

    @compiler-errors@lcnr

    Issue actions

      reblessive regression: rely on item bounds of not-yet-defined opaque types · Issue #182 · rust-lang/trait-system-refactor-initiative