Remove support for defaulted trait methods with async or return-position impl Trait

[compiler-errors]

Unfortunately, default methods on async fn and return-position impl Trait in traits are unsound and pretty unworkable in their current state. To put it in perspective, given the code:

trait Foo {
  async fn foo();
}

The above code cannot bbe desugared like:

#![feature(type_alias_impl_trait, associated_type_defaults)]

use std::future::Future;

trait Foo {
    type FooRPIT = impl Future<Output = ()>;
    
    fn foo() -> Self::FooRPIT {
        async {}
    }
}

because we shouldn't be able to observe the Self::FooRPIT -> impl Future projection.

Ideally, we could observe this inside the body of Foo::foo, but the way that our projection logic implements this is not correct, leading to issues like #107002. Fixing it leads to weird cycles or committing to really nasty hacks in HIR and MIR typeck (#107013).

---

To discourage users from relying on this behavior and hitting issues like #107002, let's just deny this behavior for now. Maybe I can revisit this feature in the future with a clearer mind. I may have some tricks up my sleeve to fix this, but for now, let's not commit to supporting this.

cc @rust-lang/wg-async and @rust-lang/types who may have thoughts about this.

r? @lcnr

Fixes #107002 (not really, but at least closes it)

[rustbot]

rustc_error_messages was changed

cc @davidtwco, @compiler-errors, @JohnTitor, @TaKO8Ki

[eholk]

I think denying default impls on async methods sounds reasonable for now, but I think it's something we should try to support in the future.

[compiler-errors]

Alternatively, lcnr and I discussed we should be able to both fix these default trait methods without removing them with #108203.

Let's wait a bit to see if that PR has any fatal flaws, otherwise I'll land this.

@rustbot blocked

[compiler-errors]

Closing in favor of #108203.