suggest await for future-related type errors

A common problem when using async-await is to forget to invoke .await. This often shows up as a type error, e.g. in a case like this (playground):

#![feature(async_await)]

async fn make_u32() -> u32 {
    22
}

fn take_u32(x: u32) {

}

async fn foo() {
    let x = make_u32();
    take_u32(x);
}

fn main() { }

currently we give a rather generic error:

error[E0308]: mismatched types
  --> src/main.rs:13:14
   |
13 |     take_u32(x);
   |              ^ expected u32, found opaque type
   |
   = note: expected type `u32`
              found type `impl std::future::Future`

it'd be nice if we could suggest adding .await somewhere.

@estebank

cc @rust-lang/wg-diagnostics @estebank

@wycats

@wycats was reporting a much worse error, but I'm quite sure what he did to encounter it:

Probably has something to do with streams?

This will be harder to do for chained expessions future.field_or_resolved_future.execute_new_future()? that should have been future.await.field_or_resolved_future.execute_new_future().await?.

@nikomatsakis

@nikomatsakis Looks like @wycats's error was the same, it's just that the output type of the future is more complicated (Pin<Box<Stream<Item = Value> + Send + 'static>>).

Hi, I'd be really interested in working on this

@DoctorN

@DoctorN awesome! Sending @rustbot claim should assign you to the issue and feel free to start a topic in the #wg-async-foundations stream if you need a hand.

@rustbot

@rustbot claim

Rollup merge of rust-lang#62067 - doctorn:await_diagnostic, r=matthew…

Here's another example where suggesting .await would be helpful (playground):

async fn a() -> Result<(), ()> {
    Ok(())
}

fn main() {
    match a() {
        Ok(()) => (),
        Err(()) => (),
    }
}

Rollup merge of rust-lang#71948 - csmoe:issue-61076, r=oli-obk

@csmoe

@csmoe Thanks for improving on this with #71948. Do you want to continue working on this, or release the assignment for now?

@tmandry

@tmandry I'll try to fix them all, more commits pending.

@estebank

From #62067, these are the cases still missing:
* [ ]  Return places for functions

* [ ]  Field access

* [ ]  Method invocation
In bodies that aren't async, .await is not suggested, but maybe we should mention that we're not in an async block and that the future could have been awaited. I guess this is likely to be a common wip error during development.

@estebank could you write a case of return-place-for-functions? I'm not sure about this one, since await seems already suggested

Indeed. I'm not sure if it is due to an improvement since august last year, or just a mistake on my part. Either way, we are in a good place today :)

@csmoe

Ping from wg-async-foundations triage. @csmoe are you still working on this?

@tmandry

@tmandry yes, in slow progress since time is tough these days.

Auto merge of rust-lang#72784 - csmoe:issue-61076, r=estebank

Navigation Menu

Repository navigation

suggest `await` for future-related type errors #61076

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

suggest await for future-related type errors #61076

Description

Activity

nikomatsakis commented on May 23, 2019

nikomatsakis commented on May 23, 2019

estebank commented on May 23, 2019

cramertj commented on May 23, 2019

cofibrant commented on Jun 17, 2019

davidtwco commented on Jun 17, 2019

cofibrant commented on Jun 17, 2019

11 remaining items

jebrosen commented on May 11, 2020

tmandry commented on May 19, 2020

csmoe commented on May 20, 2020

csmoe commented on May 20, 2020

estebank commented on May 20, 2020

tmandry commented on Jul 14, 2020

csmoe commented on Jul 15, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

suggest `await` for future-related type errors #61076