Error when implementing async method of another trait from another trait

[lohvht]

I tried this code:

trait TraitOne {
    async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()>;
}

trait TraitTwo: TraitOne {
    async fn m4(&self, a: u32) -> Result<(), ()>;
    async fn m5(&self, b: String) -> Result<(), ()>;
}

impl<T: TraitTwo> TraitOne for T {
    async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()> {
        Ok(())
    }
}
fn main() {
    println!("hello world");
}

I expected to see this happen: the above should be able to compile as the sync version of that code can also be compiled (i.e. removing all async keywords from the example above)

Instead, this happened: it gave the following error below, where the signatures match exactly but compilation still gave an error.

❯ RUST_BACKTRACE=1 cargo run
   Compiling async-trait-err v0.1.0 (/home/vloh/projects/test-async-trait)
error[E0053]: method `m3` has an incompatible type for trait
  --> src/main.rs:11:5
   |
11 |     async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected associated type, found future
   |
note: type in trait
  --> src/main.rs:2:5
   |
2  |     async fn m3<B, W>(&self, _w: &mut W, _b: B) -> Result<(), ()>;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: expected signature `fn(&T, &mut W, _) -> impl Future<Output = Result<(), ()>>`
              found signature `fn(&T, &mut W, _) -> impl Future<Output = Result<(), ()>>`

For more information about this error, try `rustc --explain E0053`.
error: could not compile `async-trait-err` (bin "async-trait-err") due to previous error

Meta

rustc --version --verbose:

rustc 1.75.0-nightly (4578435e1 2023-10-19)
binary: rustc
commit-hash: 4578435e1695863d921c7763d5a0add98f8e3869
commit-date: 2023-10-19
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.3

Backtrace

<backtrace>

[compiler-errors]

I'm pretty certain that this is a duplicate of #112626, and is unfortunate consequence of how the old trait solver works. I'll see if there's a quick fix we can enact here, but I'm somewhat doubtful 😓

[lohvht]

Thanks for getting back to me, turns out I was also overthinking my implementation and I just wanted a blanket implementation of TraitOne over TraitTwo and I didn't really need TraitTwo to have a circular impl as well (i.e. TraitTwo : TraitOne).

I still think that the diagnostic returned wasn't of help though in this case.