nested RPITIT in default methods result in type mismatch

[lcnr]

use std::ops::Deref;

trait Foo {
    fn bar() -> impl Deref<Target = impl Sized> {
        &()
    }
}

fn main() {}

error[E0271]: type mismatch resolving `<impl Deref<Target = impl Sized> as Deref>::Target == impl Sized`
 --> <source>:4:17
  |
4 |     fn bar() -> impl Deref<Target = impl Sized> {
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ
  |
note: required by a bound in `Foo::{synthetic#0}`
 --> <source>:4:28
  |
4 |     fn bar() -> impl Deref<Target = impl Sized> {
  |                            ^^^^^^^^^^^^^^^^^^^ required by this bound in `Foo::{synthetic#0}`

affected tests

• tests/ui/impl-trait/in-trait/nested-rpitit-bounds.rs
• tests/ui/impl-trait/in-trait/default-body-with-rpit.rs

[compiler-errors]

Given:

trait Foo {
    fn bar() -> impl Deref<Target = impl Sized> {
        &()
    }
}

Let's partially desugar things here just to give them names:

type RPIT1 = impl Deref<Target = RPIT2>;
type RPIT2 = impl Sized;

trait Foo {
    type GAT1: Deref<Target = Self::GAT2> = RPIT1;
    type GAT2: Sized = RPIT2;

    fn bar() -> Self::GAT1 {
        &()
    }
}

We want to prove that the default value of GAT1, namely RPIT1, satisfies the item bounds for GAT1. This requires us to prove RPIT1: Deref<Target = Self::GAT2>. We can't normalize Self::GAT2 to RPIT2 since we have a param-env of Self: Foo which shadows the normalization.

This is side-stepped in the old solver by the construction of the normalize_param_env. See rust-lang/rust#117131 for more info. Since we don't actually normalize anything in the new solver, this is insufficient.

One way to fix this would be to augment the ReplaceTy folder to actually replace RPITITs eagerly too 🤔...

[lcnr]

for now, we've agreed to deeply normalize in the normalize_param_env with the new solver as well

[compiler-errors]

This is not as easy as deeply normalizing in the normalize_param_env, since there's ambiguity between using the impl to normalize and installing a projection predicate. Consider:

trait Ref<'a> {
    type Assoc;
}
impl<'a, T> Ref<'a> for T where T: 'a {
    type Assoc = &'a T;
}

Normalizing <T as Ref<'a>>::Assoc with the normalize-param-env will have two candidates that differ in their response region: via the impl, and via a projection predicate that we install. Since we don't also install an identity trait predicate (i.e. T: Ref<'a>), then there's no preference for the projection predicate. If we do that, though, then other things get fucked up.

[compiler-errors]

1. only install normalize_param_env only if associated item is overrideable
2. change shadowing

[lcnr]

fixed by rust-lang/rust#137000