rust compiler yields obviously broken suggestions around dyn/impl use when tickled right

[erikh]

I tried this code:

So, the code is sufficiently complicated that it's really not worth it to spend all day trying to replicate. This branch has all of it. What you will want to do is cd to the vayama dir and run cargo test. That dir runs fine without privilege or touching the disk.. you do not want to run in the workspace dir or use the makefiles. Sorry I don't have something better to offer.

I expected to see this happen:

A suggestion that was syntactically correct.

Instead, this happened:

16 |           async fn successful_run_func(state: TransientState) -> MigrationFuture {
   |  ________________________________________________________________________________^
17 | |             Ok(state)
18 | |         }
   | |_________^ doesn't have a size known at compile-time
   |
   = note: the full name for the type has been written to '/home/erikh/src/github.com/trunk-os/control-plane/target/debug/deps/vayama-20c2982cc915c464.long-type-5394471838162170588.txt'
   = note: consider using `--verbose` to print the full type name to the console
help: consider returning an `impl Trait` instead of a `dyn Trait`
   |
16 |         async fn successful_run_func(state: TransientState) -> MigrationFuture impl {
   |                                                                                ++++
help: alternatively, box the return type, and wrap all of the returned values in `Box::new`
   |
16 ~         async fn successful_run_func(state: TransientState) -> MigrationFuture Box<dyn {
17 |             Ok(state)
18 ~         }>

Meta

rustc --version --verbose:

rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8

No backtrace required.

[ais523]

Manually reduced:

async fn f() -> dyn Future<Output = ()> {}

The bug report was against stable, but this still reproduces on nightly.

@rustbot label +S-has-mcve +A-dyn-trait

[ais523]

Here's a version that produces no errors other than the one with the incorrect suggestion (which is probably better for a regression test than the version above):

async fn f() -> dyn Future<Output = ()> {
    async {}
}

Using Future isn't required to trigger the bug, so you can also reproduce with other traits:

async fn f() -> dyn core::fmt::Debug {
    loop {}
}

A similar but slightly different case, involving no async, that can be produced from the same original test case by minimizing it differently:

type T = dyn core::fmt::Debug;
 
fn f() -> T { loop {} }

which produces

error[E0746]: return type cannot be a trait object without pointer indirection
 --> src/lib.rs:3:11
  |
3 | fn f() -> T { loop {} }
  |           ^ doesn't have a size known at compile-time
  |
help: consider returning an `impl Trait` instead of a `dyn Trait`
  |
3 | fn f() -> impl T { loop {} }
  |           ++++
help: alternatively, box the return type, and wrap all of the returned values in `Box::new`
  |
3 | fn f() -> Box<dyn T> { Box::new(loop {}) }
  |           +++++++  +   +++++++++       +

(This is also syntactically wrong because impl and dyn require a trait, not a type – acting on the first suggestion above gives you expected trait, found type alias `T` – but less obviously so than in the version above.)

[itsakeyfut]

It seems that for async functions returning dyn Trait, the broken suggestions like impl { or Box<dyn { might be caused by an incorrect span during async desugaring.

compiler/rustc_trait_selection/src/error_reporting/traits/suggestions.rs 1900:1906

let (pre, impl_span) = if let Ok(snip) = self.tcx.sess.source_map().span_to_snippet(span)
    && snip.starts_with("dyn ")
{
    ("", span.with_hi(span.lo() + BytePos(4)))
} else {
    ("dyn ", span.shrink_to_lo())
};

More specifically, when an async fn is desugared, the span of the return type appears to cover the entire function body.
Then, when the suggestion generator tries to locate the dyn token from that span, it actually points inside the function body (e.g., { async {} }).
As a result, the suggestion logic inserts impl right before {, producing code like impl { ... }