relating higher-ranked projections can unexpectedly constrain inference

[aliemjay]

The following compiles (although it shouldn't, arguably, see below for reasoning): https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=05d31c1cc2a9e8752d7a3fc05e9446ea

pub trait Trait {
    type Ty<'a>;
}

fn my_fn<T: Trait>(_: T::Ty<'_>) {}

fn test<A: Trait, B: Trait>() -> impl Fn(A::Ty<'static>) {
    my_fn
}

It stops compiling with a trivial change that gets rid of higher-ranked regions:

- fn my_fn<T: Trait>(_: T::Ty<'_>) {}
+ fn my_fn<T: Trait>(_: T::Ty<'static>) {}

fn test<A: Trait, B: Trait>() -> impl Fn(A::Ty<'static>) {
    my_fn
+   //~^ ERROR type annotation needed
}

This was discovered by @BoxyUwU in #96912.

@rustbot label T-types C-bug I-unsound A-inference

[aliemjay]

Here is a variant that shows why it's unsound; Inference ambiguity is accepted here:

pub trait Trait {
    type Ty<'a>;
}

fn my_fn<T: Trait>(_: T::Ty<'_>) {}

fn test<A, B>() -> impl Fn(A::Ty<'static>)
where
    A: Trait,
    B: for<'a> Trait<Ty<'a> = A::Ty<'a>>,
{
    my_fn::<_> // A and B are both valid options; We pick A!
}

[compiler-errors]

I think this needs a better example for the unsoundness. The inference variable being constrained by one where-clause predicate over the other is not unsound, regardless of whether we think that the behavior is surprising.

At least, this is totally fine to do inside of a function body, I thought?

[aliemjay]

After the discussion in a zulip thread, I agree that this is not necessarily a soundness bug. 😅

@rustbot label -I-unsound

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium