propagate opaque types to the typeck root

[lcnr]

still far from properly working

r? @compiler-errors

[bors]

☔ The latest upstream changes (presumably #135465) made this pull request unmergeable. Please resolve the merge conflicts.

[lcnr]

alright, there are still a few hacks and bad diagnostics, but it's otherwise working as intended. Going to do a crater run to check whether it's breaking anything.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 3d6168a with merge cabf407...

[aliemjay]

I am not current with the state of the new solver, but no matter how I think about it, I find it difficult to justify the added complexity (edit: of this PR, not the solver :). Member constraints are not simple post-inference checks—they directly impact region inference, and simply propagating them to the parent function renders them ineffective.

Is the goal here to allow defining opaque types with external lifetime arguments inside closures? If so, this approach does not work once the hidden type contains lifetimes

struct Relate<T>(T, T);
fn test<'a>() -> impl Sized + 'a {
    || Relate("", test::<'a>()); // Opaque<'a> := &'empty str
    "" // Opaque<'a> := &'a str
}

[lcnr]

struct Relate<T>(T, T);
fn test<'a>() -> impl Sized + 'a {
    || Relate("", test::<'a>()); // Opaque<'a> := &'empty str
    "" // Opaque<'a> := &'a str
}

This also works with this approach as we lift 'local to be a fresh external region as well. SO we propagate exists<'whatever>: Opaque<'a> = &'whatever str to the parent fn which then proves this.

The only pattern I am aware of which is not supported by this approach is the following (regardless of whether we're in a closure)

struct Foo;
impl Foo {  
    fn recur<'a>(&'a self, b: bool) -> impl Sized + 'a {
        if b {
            let temp = Foo;
            // temp.recur(borrow, false);
            let borrow = &temp;
            Foo::recur(borrow, false); // defines in new solver, opaque use in old
        }
    }
}

And that's more a general issue of this recursive call being a defining one. Fixing this one requires a different perspective on opaques to allow non-defining uses in the defining scope

[aliemjay]

So hidden type regions are lifted as well. Interesting indeed. 👍

This puts a heavy strain on the "region constraint propagation" code, which has a poor track record and, in some cases, is only approximate, as you encountered in #104477.

[bors]

☔ The latest upstream changes (presumably #135615) made this pull request unmergeable. Please resolve the merge conflicts.

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

   Compiling rustc_borrowck v0.0.0 (/checkout/compiler/rustc_borrowck)
error: unused import: `Obligation`
  --> compiler/rustc_borrowck/src/type_check/mod.rs:22:27
   |
22 | use rustc_infer::traits::{Obligation, ObligationCause, PredicateObligations};
   |
   = note: `-D unused-imports` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(unused_imports)]`


   Compiling rustc_codegen_llvm v0.0.0 (/checkout/compiler/rustc_codegen_llvm)
error: unused variable: `fr_fn_body`
  --> compiler/rustc_borrowck/src/type_check/opaque_types.rs:47:9
   |
47 |     let fr_fn_body = ty::Region::new_var(
   |         ^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_fr_fn_body`
   = note: `-D unused-variables` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(unused_variables)]`

error: could not compile `rustc_borrowck` (lib) due to 2 previous errors

[compiler-errors]

@rustbot author since this is still draft/being worked on i think?

[bors]

☔ The latest upstream changes (presumably #136085) made this pull request unmergeable. Please resolve the merge conflicts.