Require impl Trait in associated types to appear in method signatures

[oli-obk]

This implements the limited version of TAIT that was proposed in #107645 (comment)

Similar to impl Trait in return types, impl Trait in associated types may only be used within the impl block which it is a part of. To make everything simpler and forward compatible to getting desugared to a plain type alias impl trait in the future, we're requiring that any associated functions or constants that want to register hidden types must be using the associated type in their signature (type of the constant or argument/return type of the associated method. Where bounds mentioning the associated type are ignored).

We have preexisting tests checking that this works transitively across multiple associated types in situations like

impl Foo for Bar {
    type A = impl Trait;
    type B = impl Iterator<Item = Self::A>;
    fn foo() -> Self::B { ...... }
}

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @compiler-errors (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[compiler-errors]

Sorry for the delay. Here's some initial implementation thoughts.

[aliemjay]

Do we have a test for this case?:

trait Trait {
    type Item;
    type Iter: IntoIterator<Item = Self::Item>;
    fn iter() -> Self::Iter;
}
impl Trait for () {
    type Item = impl Sized;
    type Iter = impl IntoIterator<Item = Self::Item>;
    fn iter() -> Self::Iter { None::<()> }
}

I think it's pretty reasonable to allow fn iter to constrain impl Sized, but we should probably have an explicit t-lang decision here?

I also suggest adding a couple tests:

// check-fail
// revisions: compare_ty compare_method
#![feature(impl_trait_in_assoc_type)]

#[cfg(compare_ty)]
mod compare_ty {
    trait Trait {
        type Ty: IntoIterator<Item = ()>;
    }
    impl Trait for () {
        type Ty = Option<impl Sized>;
    }
}

#[cfg(compare_method)]
mod compare_method {
    trait Trait {
        type Ty;
        fn method() -> Self::Ty;
    }
    impl Trait for () {
        type Ty = impl Sized;
        fn method() -> () {}
    }
}

[aliemjay]

why DefKid::AssocTy?

[oli-obk]

I added a comment for that. The reason for that is that we do wf checks of opaque types within their parent. So we need to treat their parent as having them in the signature, as we'd otherwise fail that wf check. The wfcheck is fishy anyway and we're working on removing it, so that will go away once we remove the wfcheck

[oli-obk]

I still need to look into @aliemjay's review, but I was able to get rid of many of the problems we had with the approach by replacing it entirely. It now mirrors ImplTraitInTraitFinder and I plan to see if there is some deduplication that can be done between the two.

[oli-obk]

I think it's pretty reasonable to allow fn iter to constrain impl Sized, but we should probably have an explicit t-lang decision here?

Yes, we do have https://github.com/rust-lang/rust/blob/master/tests/ui/generic-associated-types/issue-89008.rs

I don't think this feature makes sense without automatically recursing into other associated types from the same impl block.

[oli-obk]

@rustbot ready

[bors]

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

[oli-obk]

@rustbot ready

[oli-obk]

@rustbot ready

sorry everyone, no clue what happened here

[BoxyUwU]

It's okay its your first time making a PR here, it happens :)

[oli-obk]

@bors r=compiler-errors

[bors]

📌 Commit 5cd56f11622c1311c3b54d734d5089e3200b3f7c has been approved by compiler-errors

It is now in the queue for this repository.

[oli-obk]

@bors r-

[oli-obk]

@bors r=compiler-errors

[bors]

📌 Commit 4e92f76 has been approved by compiler-errors

It is now in the queue for this repository.