Split tait and impl trait in assoc items logic

[oli-obk]

And simplify the assoc item logic where applicable.

This separation shows that it is easier to reason about impl trait in assoc items compared with TAITs. See https://rust-lang.zulipchat.com/#narrow/stream/315482-t-compiler.2Fetc.2Fopaque-types/topic/impl.20trait.20in.20associated.20type for some discussion.

The current plan is to try to stabilize impl trait in associated items before TAIT, as they do not have any issues with their defining scopes (see #107645 for why this is not a trivial or uncontroversial topic).

[compiler-errors]

Add additional test:

#![feature(impl_trait_in_assoc_type)]

trait Trait {
    type Assoc;
    
    fn t() -> Struct;
}

struct Struct {
  field: <() as Trait>::Assoc,
}

impl Trait for () {
    type Assoc = impl Sized;
    
    fn t() -> Struct {
        Struct { field: () }
    }
}

[compiler-errors]

One question -- why does this need to be separate? Shouldn't this work with the regular find_opaque_ty_constraints_for_tait, as long as typeck uses the right def-ids collected from ImplTraitInAssocTypeCollector?

[compiler-errors]

Are we still checking the nested bodies of associated items? Pls check if this example (which constrains an ITIAT incorrectly inside of a closure body) still fails:

#![feature(impl_trait_in_assoc_type)]

trait Foo {
  type Assoc;
  fn bar() -> Self::Assoc;
}

impl Foo for () {
  type Assoc = impl Sized;
  fn bar() -> Self::Assoc {
    let closure = || -> Self::Assoc { let x: Self::Assoc = (); x };
    let _: i32 = closure();
    1i32
  }
}

[oli-obk]

Doesn't need to be separate per se, but the new impl is so straight forward... and if the TAIT impl changes, we don't need to worry about the ITAIT impl at all.

[compiler-errors]

Are we still checking the nested bodies of associated items? Pls check if this example (which constrains an ITIAT incorrectly inside of a closure body) still fails:

#![feature(impl_trait_in_assoc_type)]

trait Foo {
  type Assoc;
  fn bar() -> Self::Assoc;
}

impl Foo for () {
  type Assoc = impl Sized;
  fn bar() -> Self::Assoc {
    let closure = || -> Self::Assoc { let x: Self::Assoc = (); x };
    let _: i32 = closure();
    1i32
  }
}

[oli-obk]

Add additional test:

we already have this test: https://github.com/rust-lang/rust/blob/4f8ebacbaaa494f17e4a570b98b5ef638b77d5de/tests/ui/type-alias-impl-trait/hidden_behind_struct_field2.rs

[compiler-errors]

Please also add this as a test:

#![feature(impl_trait_in_assoc_type)]

trait Foo {
    type Assoc<'a, 'b>;
    fn bar<'a: 'a, 'b: 'b>(_: &'a ()) -> Self::Assoc<'a, 'b>;
}

impl Foo for () {
    type Assoc<'a, 'b> = impl Sized;
    fn bar<'a: 'a, 'b: 'b>(x: &'a ()) -> Self::Assoc<'a, 'b> {
        let closure = |x: &'a ()| -> Self::Assoc<'b, 'a> {
            x
        };
        x
    }
}

fn main() {}

I don't know why it's failing actually, because it seems unrelated. But if it ever got fixed, then I'd want to see it not become unsound.

r=me afterwards

[compiler-errors]

@rustbot author

[traviscross]

I don't know why it's failing actually, because it seems unrelated. But if it ever got fixed, then I'd want to see it not become unsound.

[Edit (see below):] Here's a different interesting issue found while trying to minimize this one.

#![feature(impl_trait_in_assoc_type)]

trait Foo {
    type Assoc<'a>;
    fn bar();
}

impl Foo for () {
    type Assoc<'a> = impl Sized;
    fn bar()
    where
        for<'a> Self::Assoc<'a>:,
    {
        let _ = |x: &()| -> Self::Assoc<'_> { x };
        //~^ ERROR hidden type for `<() as Foo>::Assoc<'_>` captures lifetime that does not appear in bounds
        //
        // If we ascribe the type to:
        //
        //     for<'b> fn(&'b ()) -> Self::Assoc<'b>
        //
        // ...then this works.
    }
}

fn main() {}

[compiler-errors]

@traviscross: I don't believe that is a faithful reproduction of the error I mentioned. Your example has to do with the fact that you cannot have a definition of an opaque's hidden type capture any higher-ranked lifetimes.

edit: actually, I don't even think it's that. I just think that in that example, the opaque's lifetime isn't being constrained to a universal lifetime at all.

Notice that in my example that closure has a signature that only references lifetimes that are coming from the parent function.

[traviscross]

We talked off-thread and agreed that in the example I gave it is surprising that ascribing the type there makes it work. But as @compiler-errors helpfully pointed out, it's likely a separate issue. In that light, here's a corrected faithful minimization stated in terms of ATPIT:

#![feature(impl_trait_in_assoc_type)]

trait Foo {
    type Assoc<'a>;
    fn bar<'a: 'a>();
}

impl Foo for () {
    type Assoc<'a> = impl Sized;
    fn bar<'a: 'a>()
    where
        Self::Assoc<'a>:,
    {
        let _ = |x: &'a ()| {
            let _: Self::Assoc<'a> = x;
            //~^ ERROR hidden type for `<() as Foo>::Assoc<'a>` captures lifetime that does not appear in bound
        };
    }
}

fn main() {}

Here is what I would suspect to be an RPIT minimization of the same issue:

use core::convert::identity;

fn test<'a: 'a>(n: bool) -> impl Sized + 'a {
    let true = n else { loop {} };
    let _ = || {
        let _ = identity::<&'a ()>(test(false));
        //~^ ERROR hidden type for `impl Sized + 'a` captures lifetime that does not appear in bounds
    };
    loop {}
}

fn main() {}

[oli-obk]

@bors r=compiler-errors

[bors]

📌 Commit 5e5d135 has been approved by compiler-errors

It is now in the queue for this repository.