return-type mismatch in async function gives "return type inferred" pointing to use of `?`

[joshtriplett]

Given the following code (playground link):

async fn func() -> Result<u16, u64> {
    let _ = async {
        Err(42u64)
    }.await?;

    Ok(())
}

The current output is:

error[E0308]: mismatched types
 --> src/lib.rs:6:8
  |
6 |     Ok(())
  |        ^^ expected `u16`, found `()`
  |
note: return type inferred to be `u16` here
 --> src/lib.rs:2:13
  |
2 |       let _ = async {
  |  _____________^
3 | |         Err(42u64)
4 | |     }.await?;
  | |____________^

error: aborting due to previous error

An even more minimal example:

async fn func() -> Result<u16, u64> {
    Err(42u64)?;

    Ok(())
}

This similarly produces a note pointing to the Err(42u64)?; line.

The note seems entirely unhelpful here; the function's declared type doesn't match the Ok(()), and the use of ? has nothing to do with it. An equivalent non-async function omits the note, and just reports the type mismatch.

The same output occurs on both stable and today's nightly.

[FabianWolff]

I think this is unrelated to both the async and the ? (they just "hide" the problem), because I can reproduce the problem as follows:

fn main() {
    || -> Result<u16, u64> {
        if true {
            return Err(42u64);
        }
        Ok(())
    };
}

error[E0308]: mismatched types
 --> test.rs:6:12
  |
6 |         Ok(())
  |            ^^ expected `u16`, found `()`
  |
note: return type inferred to be `u16` here
 --> test.rs:4:20
  |
4 |             return Err(42u64);
  |                    ^^^^^^^^^^

error: aborting due to previous error

It is caused by the fact that ret_coercion_span (which is used for error reporting later) is set to the span of the first return statement here:

rust/compiler/rustc_typeck/src/check/expr.rs

Lines 725 to 730 in 478126c

	} else if let Some(e) = expr_opt {
	if self.ret_coercion_span.get().is_none() {
	self.ret_coercion_span.set(Some(e.span));
	}
	self.check_return_expr(e);
	} else {

despite the fact that this only partially defines the return type (it doesn't say anything about the Ok type).

[FabianWolff]

@rustbot claim