Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

redundant_async_block not catching uses with nontrivial futures #12732

Open
jwodder opened this issue Apr 29, 2024 · 1 comment
Open

redundant_async_block not catching uses with nontrivial futures #12732

jwodder opened this issue Apr 29, 2024 · 1 comment
Labels
C-bug Category: Clippy is not doing the correct thing I-false-negative Issue: The lint should have been triggered on code, but wasn't

Comments

@jwodder
Copy link

jwodder commented Apr 29, 2024

Summary

The redundant_async_block lint fails to trigger on uses of async { EXPRESSION.await } for seemingly any EXPRESSION other than a single variable.

Lint Name

redundant_async_block

Reproducer

I tried this code:

use std::future::ready;

pub fn foo() {
    tokio::spawn(async { ready(42).await });
}

I expected to see this happen: clippy should have warned about the redundant async block and recommended just writing tokio::spawn(ready(42)) instead.

Instead, this happened: no warnings

Version

rustc 1.77.2 (25ef9e3d8 2024-04-09)
binary: rustc
commit-hash: 25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04
commit-date: 2024-04-09
host: x86_64-apple-darwin
release: 1.77.2
LLVM version: 17.0.6
@jwodder jwodder added C-bug Category: Clippy is not doing the correct thing I-false-negative Issue: The lint should have been triggered on code, but wasn't labels Apr 29, 2024
@y21
Copy link
Member

y21 commented Apr 29, 2024

They are semantically different if the expression has side effects.

async { some_function().await } only executes the function call on the first poll, whereas some_function() eagerly calls the function.
ready happens to not have any side effects where this would be noticeable, but the lint doesn't know that and assumes that it does because it's a function call.

(!expr.can_have_side_effects() || desugar_async_block(cx, expr).is_some()) &&

See also #10509.

We could probably make it emit a warning when an async fn is called, because for those there is no difference, but that wouldn't fix this specific reproducer with the ready function, because that is a normal function returning a specific Ready type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing I-false-negative Issue: The lint should have been triggered on code, but wasn't
Projects
None yet
Development

No branches or pull requests

2 participants