Unhelpful "cannot infer type" error for ? in async block with unclear Result Err type

[joshtriplett]

Minimal reproduction:

fn may_error() -> Result<(), ()> { unimplemented!() }

fn main() {
    async {
        may_error()?;
        Ok(())
    };
}

1.47.0 gives the following error:

error[E0282]: type annotations needed
 --> src/main.rs:5:9
  |
5 |         may_error()?;
  |         ^^^^^^^^^^^^ cannot infer type

Nightly gives a marginally more useful error:

error[E0282]: type annotations needed
 --> src/main.rs:5:20
  |
5 |         may_error()?;
  |                    ^ cannot infer type

I would expect an explanation of what type precisely couldn't be inferred, along with a pointer to the containing async block as the thing whose type couldn't be inferred.

rustc --version --verbose (for 1.47.0):

rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

rustc --version --verbose (for nightly):

rustc 1.49.0-nightly (c71248b70 2020-10-11)
binary: rustc
commit-hash: c71248b70870960af9993de4f31d3cba9bbce7e8
commit-date: 2020-10-11
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0

[jyn514]

Turning this into a closure gives a more helpful error:

error[E0282]: type annotations needed for the closure `fn() -> std::result::Result<(), _>`
 --> src/lib.rs:5:9
  |
5 |         may_error()?;
  |         ^^^^^^^^^^^^ cannot infer type
  |
help: give this closure an explicit return type without `_` placeholders
  |
4 |     let g = || -> std::result::Result<(), _> {
  |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[joshtriplett]

@jyn514 Yeah, I found that several different code changes led to better errors.

I'd guess part of the issue is that there's no stable way to add a type annotation directly to an async block.

[tmandry]

We should update the part of the code that emits the help text for closures (search for give this closure an explicit return type) to fall back to another error message for async blocks.

Maybe we can still print the type as in the closure case, just to point to the _ as the part we can't infer? It might take some experimenting to get the presentation right.

[hameerabbasi]

I'm willing to take a shot at this.

@rustbot claim

[tmandry]

@hameerabbasi Are you still planning to work on this?

[hameerabbasi]

Yes, I am, it fell off my radar.

[hameerabbasi]

Ah, I recall what happened here. Here's the Zulip stream: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/Picking.20up.20issue.20.20.2377880

Basically, I wasn't familiar enough with the internals of the compiler to fix this, unfortunately.

[hameerabbasi]

I'm willing to work on this, but I'll unassign myself so it's more discoverable.

@rustbot release-assignment

[wabain]

It looks like there are a few factors here. One is that impl Trait bindings can't have types annotated explicitly. With #![feature(impl_trait_in_bindings)] we can get at least some details in the error, although not as much as would be desirable:

error[E0282]: type annotations needed for `impl Future`
  --> $DIR/cannot-infer-async-enabled-impl-trait-bindings.rs:13:20
   |
LL |     let fut = async {
   |         --- consider giving `fut` the explicit type `impl Future`, with the type parameters specified
LL |         make_unit()?;
   |                    ^ cannot infer type

The other is that the diagnostics code is oriented around identifying the type of a local variable or function parameter which can be annotated—even when the annotation which will be suggested doesn't involve that binding, like specifying the return type of a closure. This means that the type of an async block will never be described directly because in the desugaring it's wrapped in a GenFuture. It's also possible to get a similar uninformative error message with a closure:

fn may_error() -> Result<(), ()> { Err(()) }

fn consume_closure<T, F: Fn() -> T>(_: F) {}

fn f() {
    consume_closure(|| {
        may_error()?;
        Ok(())
    });
}

Gives:

error[E0282]: type annotations needed
 --> src/lib.rs:7:20
  |
7 |         may_error()?;
  |                    ^ cannot infer type

If the closure is assigned to a local variable before being passed to consume_closure, the error is much better:

error[E0283]: type annotations needed for the closure `fn() -> std::result::Result<(), _>`
  --> src/lib.rs:14:20
   |
14 |         may_error()?;
   |                    ^ cannot infer type
   |
   = note: cannot satisfy `_: From<()>`
   = note: required by `from`
help: give this closure an explicit return type without `_` placeholders
   |
13 |     let v = || -> std::result::Result<(), _> {
   |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm interested in trying to clean this up a bit. @rustbot claim.

[wabain]

I’d assumed fixing this would involve making the diagnostics aware of generators, but I can’t actually see how much that could be leveraged for async blocks. After looking at this some more I can think of two things we can do here, neither of which are actually specific to async blocks.

First, I think it could be helpful to have an additional note in general when inference fails for the ? operator return, explaining the From conversion applied; I think this is probably a fairly common source of confusion for people learning Rust. We can print the partially inferred From bound which needs to be satisfied. (I haven’t looked at exactly how to implement this, but I’m imagining that we’d check the desguaring kind for the primary span and then walk the HIR to recover the pre-coercion type, in this case the return of may_error().) There might be some work needed to keep it from being too redundant or verbose (or maybe too terse, if the error type of the value ? is invoked on isn't inferred) but I think it would be doable.

Where possible, we can also suggest annotating another expression which would disambiguate the return type. This is actually already supported in some cases, like if a Result returned without ?-coercion is first bound to a local variable, or if the error type occurs as a parameter in a method (but not function!) call. It should be possible to give a similar suggestion to annotate an Ok constructor with the error type.

Putting the suggestions together, the output for the initial example in this issue could be something like:

error[E0282]: type annotations needed
 --> src/main.rs:5:21
  |
5 |         may_error()?;
  |                    ^ cannot infer type of `?` return
  |
  = note: The `?` operator can convert the error value to any type which implements `From<std::io::Error>`
help: consider specifying the type arguments when constructing `std::result::Result::Ok`
  |
6 |         Ok::<T, E>(())
  |           ^^^^^^^^

[wabain]

It looks like there are some good mismatched type diagnostics to piggyback off of.

[tmandry]

Both of these suggestions sound really nice, I hope we can implement them!

[tmandry]

Triage: nightly now gives

error[E0282]: type annotations needed
 --> src/main.rs:5:20
  |
5 |         may_error()?;
  |                    ^ cannot infer type of error for `?` operator
  |
  = note: `?` implicitly converts the error value into a type implementing `From<()>`

thanks to #80517 (thanks @wabain)! I think this means the issue is fixed.