#[must_use] on async fns works on returned Future instead of the awaited value

[ghost]

I tried this code:

#[must_use]
async fn foo() -> i32 {
    std::future::pending().await
}

pub fn with_warnings() {
    foo();
}

pub async fn without_warning() {
    foo().await;
}

I expected the compiler to warn about the unused return value in without_warning(), but the compiler emitted two warnings in with_warnings():

warning: unused implementer of `Future` that must be used
 --> src/lib.rs:7:5
  |
7 |     foo();
  |     ^^^^^^
  |
  = note: `#[warn(unused_must_use)]` on by default
  = note: futures do nothing unless you `.await` or poll them

warning: unused return value of `foo` that must be used
 --> src/lib.rs:7:5
  |
7 |     foo();
  |     ^^^^^^

Playground (tried using nightly 2020-10-18 b1496c6)

As the real return values of async fns are actually impl Futures, you may consider this as the expected behavior (I don't agree, and impl Futures are already #[must_use]). If that is the case, there should be a way to make the compiler warn on unused .awaited values (when type of the .awaited value is not #[must_use]).

@rustbot modify labels: A-async-await A-lint -A-diagnostics

[tmandry]

I think this is indeed a bug, or at the very least unexpected behavior. It might be challenging to fix, since I don't know of a way to express the desired desugaring.

[nikomatsakis]

I agree that this will be challenging. The first problem as you said is that, in the desugaring, the #[must_use] is being applied to the function that returns the impl Future, and we don't have a clear place where it would be applied to mean "the value awaited by this future". So that's something we'd have to teach the lint somehow.

Second problem then would be that the lint would have to have the idea of a "must use future" (let's call it), and it would have to track when that future is awaited and figure out that the resulting value is itself #[must_use].

I'm pondering if there is a generalization that might make this easier and less special case, not clear.

[tmandry]

In the short term we could make a lint to warn people who use the attribute on async fns that it won't do anything.

[camelid]

Assigning P-medium and removing I-prioritize as discussed in the prioritization working group.

[jinpan]

A hacky workaround for this is to wrap the return type inside a Result:

async fn bar() -> Result<(), i32> {
    std::future::pending().await
}

pub async fn async_with_warnings() {
    bar().await;
}

and the compiler will emit warnings for the unused result.

Playground link

[guswynn]

@rustbot claim

At least "In the short term we could make a lint to warn people who use the attribute on async fns that it won't do anything." part

[eholk]

@rustbot label AsyncAwait-Polish

[rustbot]

Error: Label AsyncAwait-Polish can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

[tmandry]

@rustbot label AsyncAwait-Polish

[ijackson]

A similar issue arises with fehler, withoutboats/fehler#45. In fact, it would be nice in general to be able to say, for a function which returns Result<Wombat,SomeError>, that the Wombat must be used. #[must_use] doesn't work there either, because it just demands use of the Result.

Another way to look at this is that both Result and Future have syntactic sugar for unpacking and implementing control flow effects, which makes them both special in that their contained type is somehow the "underlying" "real" return type of the function.