Invalid 'compatible variant' suggestion on mismatched types in .await expression

[m-ou-se]

This code:

async fn a() {}

async fn b() -> Result<(), i32> {
    a().await
}

produces:

error[E0308]: mismatched types
 --> src/main.rs:4:8
  |
4 |     a().await
  |        ^^^^^^ expected enum `Result`, found `()`
  |
  = note:   expected enum `Result<(), i32>`
          found unit type `()`
help: try wrapping the expression in `Ok`
  |
4 |     a()Ok(.await)
  |        +++      +

Which is invalid.

Looks like the span of the desugaring of .await uses only the .await part, instead of the span of the entire expression. This results in invalid suggestions when used by the suggest_compatible_variants code in compiler/rustc_typeck/src/check/demand.rs.

[m-ou-se]

I'm not entirely sure if this means that .await desugaring should use a bigger span, or if the suggestion diagnostic needs to be interpreted differently.

[compiler-errors]

hmm.. is .await the only case where the desugared expr's span doesn't cover the whole piece of code it comes from? That doesn't sound right.

If wonder if the expr should have the bigger span by default, and then async-specific code could grab the tighter span for diagnostics that need to point at the .await operator.

[m-ou-se]

Some of the ? desugaring only uses the ? span, but the parts relevant for diagnostics like this do use the full span. Not sure if there's a problem there too.

[m-ou-se]

I thought I might have accidentally introduced this bug in #90575, but right after that PR was merged, the output was correct:

help: try wrapping the expression in `Ok`
  |
4 |     Ok(a().await)
  |     +++         +

So something changed in the last two months in what spans are used for await desugarings, it seems.

[compiler-errors]

@m-ou-se: actually I think it was introduced in #90939 in 7227a87, cc @estebank
Do you need someone to fix this? I'm happy to put up a quick PR.

[m-ou-se]

Yeah, looks like it: I just finished bisecting, which pointed at #91945: a rollup involving #90939.

[estebank]

@compiler-errors this was introduced in the PR linked earlier to try and improve other errors. It is tricky because reducing the span to only .await incurs these kind of bugs. On the other hand, the errors that got improved there became much less noisy, so I wouldn't want to revert the whole change. My fix above will solve this issue, but I'm sure there will be others in the future :-/