Open
Description
With async/await
coming up, we will probably see an uptake of such code:
async hello() {
println!("hello").
}
Users will most likely not be aware that the call to println
are blocking. The same goes to any use of the stdlib io apis, most famously to_socket_addr()
calls.
I think there is a chance for clippy to at least find obvious cases of this, for a list of known functions.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
.wait()
,block_on
, etc.) #4427hwchen commentedon Nov 25, 2019
thread::sleep
seems to be a pretty common mistake:https://old.reddit.com/r/rust/comments/e1gxf8/not_understanding_asyncawait_properly/
https://old.reddit.com/r/rust/comments/dtp6z7/what_can_i_actually_do_with_the_new_async_fn/
https://old.reddit.com/r/rust/comments/dt0ruy/how_to_await_futures_concurrently/
thread::sleep
inside an async fn rust-lang/async-book#64kornelski commentedon May 12, 2020
thread::sleep
is a major offender. I've found that mistake done several times in a real-world codebase.Rollup merge of rust-lang#72141 - kornelski:dontsleep, r=joshtriplett
Rollup merge of rust-lang#72141 - kornelski:dontsleep, r=joshtriplett
Rollup merge of rust-lang#72141 - kornelski:dontsleep, r=joshtriplett
estebank commentedon May 17, 2024
I'm currently working on a linter that does exhaustive call-graph analysis to detect indirect usages of blocking calls in async functions. Right now this is working well, and requires either annotations (
#[redpen::blocking]
) or adding a fully-qualified path to a list::std::thread::sleep
).The exhaustive check might never land on
rustc
itself due to perf considerations (although I would love if it could be upstreamed to clippy once its more mature) but we can lint on the "simple"/direct case (async fn foo(t: Duration) { sleep(t) }
) relatively easily. In order to do that, it'd be a good idea to add an annotation forblocking
to the language.Adding a top-level attribute feels like a waste, and restricting it to the
clippy
feels wrong, but we now have the#[diagnostic]
namespace, so we could annotatestd::thread::sleep
and the like with#[diagnostic::blocking]
for the benefit of bothrustc
andclippy
to lint against direct uses (and my tool can get those attributes itself for its analysis and lint against indirect uses) and it provides crate authors a way to specify that their functions are blocking and their incorrect direct usage will also get linted.CC @weiznich
Edit: created rust-lang/rfcs#3639 proposing this.
#[diagnostic::blocking]
attribute rust-lang/rfcs#36392 remaining items