AFIT: strange errors on circular impls

[Dirbaio]

case 1 playground:

pub trait Foo {
    async fn foo(&mut self);
}

impl<T: Foo> Foo for T {
    async fn foo(&mut self) {}
}

case 2 playground:

pub trait Foo {
    async fn foo(&mut self);
}

pub trait Bar: Foo {
    async fn bar(&mut self);
}

impl<T: Bar> Foo for T {
    async fn foo(&mut self) {}
}

fails with a strange error. The equivalent without AFIT is accepted, but the impls are considered to apply to no type because they're circular turns out the version with 2 traits does result in usable impls, it's an odd way of doing extension traits: playground. So I do think these should compile.

error[[E0053]](https://doc.rust-lang.org/nightly/error_codes/E0053.html): method `foo` has an incompatible type for trait
 --> src/lib.rs:8:29
  |
8 |     async fn foo(&mut self) {}
  |                             ^ expected associated type, found future
  |
note: type in trait
 --> src/lib.rs:4:28
  |
4 |     async fn foo(&mut self);
  |                            ^
  = note: expected signature `fn(&mut T) -> impl Future<Output = ()>`
             found signature `fn(&mut T) -> impl Future<Output = ()>`

@rustbot label F-async_fn_in_trait

[bugadani]

Can I do...?

@rustbot label C-bug

[compiler-errors]

To be clear, this doesn't work with regular associated types --

pub trait Foo {
    type Assoc;

    fn foo(&mut self) -> Self::Assoc;
}

pub trait Bar: Foo {
    fn bar(&mut self) -> Self::Assoc;
}

impl<T: Bar> Foo for T {
    type Assoc = ();

    fn foo(&mut self) -> Self::Assoc {}
}

fn main() {}

So it "makes sense" why this doesn't work for AFIT, as unfortunate it is, since AFITs work like regular associated types in terms of projection.

This should work in the new trait solver (except for the fact that the new trait solver doesn't support RPITIT, which is blocked by other things 😅)

--

I'm gonna mark this as not a blocker for RPITIT stabilization, since it will probably be fixed in a non-backwards-compatible way in the future.

[compiler-errors]

@Dirbaio: do you have some info for why you're constructing such circular impls in the first place? I think it may help with the prioritization of this issue if there's some common way of encountering this issue, because it seems somewhat contrived right now.

[bugadani]

This report is the result of me not noticing that my intended use case doesn't require the Foo supertrait on Bar. We managed to figure out how I was overthinking my code and removing the supertrait solved my original issue.

This report was opened because of ekuber's view that unhelpful diagnostics should be considered bugs.