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

Add a lint for an async block/closure that yields a type that is itself awaitable. #5909

Merged
merged 3 commits into from
Aug 31, 2020

Conversation

khuey
Copy link
Contributor

@khuey khuey commented Aug 15, 2020

This catches bugs of the form

tokio::spawn(async move {
let f = some_async_thing();
f // Oh no I forgot to await f so that work will never complete.
});

See the two XXXkhuey comments and the unfixed _l structure for things that need more thought.

Please keep the line below
changelog: none

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @flip1995 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Aug 15, 2020
@Manishearth Manishearth requested a review from yaahc August 15, 2020 00:59
@Manishearth
Copy link
Member

r? @yaahc bc you like async stuff iirc

@rust-highfive rust-highfive assigned yaahc and unassigned flip1995 Aug 15, 2020
@bors
Copy link
Contributor

bors commented Aug 16, 2020

☔ The latest upstream changes (presumably #5894) made this pull request unmergeable. Please resolve the merge conflicts.

@khuey khuey force-pushed the async_yields_async branch 2 times, most recently from 9d687ee to 3f1d5ee Compare August 16, 2020 22:54
Copy link
Member

@yaahc yaahc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, just have one test case that I think might be good to add, assuming I understood the comment in check_body correctly.

clippy_lints/src/async_yields_async.rs Show resolved Hide resolved
tests/ui/async_yields_async.stderr Outdated Show resolved Hide resolved
clippy_lints/src/async_yields_async.rs Show resolved Hide resolved
clippy_lints/src/async_yields_async.rs Outdated Show resolved Hide resolved
clippy_lints/src/async_yields_async.rs Outdated Show resolved Hide resolved
clippy_lints/src/async_yields_async.rs Show resolved Hide resolved
Comment on lines +66 to +67
let _n = async || custom_future_type_ctor();
let _o = async || f();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why aren't these two triggering the lint here? I can understand that their definitions shouldn't trigger the lint but these usages seem like they should.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an example of the limitations of having to match a zillion AST types to deduce return_expr_span :(

There's no case for these so they don't warn.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, do you mean the XXXhuey bit, as in, this doesn't resolve to either a Block or a Path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea it feels like there has to be a way to handle this...

@bors
Copy link
Contributor

bors commented Aug 25, 2020

☔ The latest upstream changes (presumably #5952) made this pull request unmergeable. Please resolve the merge conflicts.

…lf awaitable.

This catches bugs of the form

tokio::spawn(async move {
    let f = some_async_thing();
    f // Oh no I forgot to await f so that work will never complete.
});
@khuey
Copy link
Contributor Author

khuey commented Aug 29, 2020

Given that nobody knows a better way forward with return_expr_span, I'd like to land this as is and more cases can be added later.

@Manishearth
Copy link
Member

Seems fair. @yaahc ?

@yaahc
Copy link
Member

yaahc commented Aug 31, 2020

sounds good to me

@bors r+

@bors
Copy link
Contributor

bors commented Aug 31, 2020

📌 Commit 04912ca has been approved by yaahc

@bors
Copy link
Contributor

bors commented Aug 31, 2020

⌛ Testing commit 04912ca with merge 8334a58...

@bors
Copy link
Contributor

bors commented Aug 31, 2020

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: yaahc
Pushing 8334a58 to master...

@bors bors merged commit 8334a58 into rust-lang:master Aug 31, 2020
@SichangHe
Copy link

more improvement

this code should still be avoid:

tokio::spawn(async move {
    some_async_thing().await
});

if some_async_thing().await is the only expression in the closure && no statement is in the closure
it should be written as

tokio::spawn(some_async_thing());

correct me if I'm wrong

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants