- Notifications
You must be signed in to change notification settings - Fork 1.8k
Open
Labels
C-bugCategory: Clippy is not doing the correct thingCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't haveIssue: The lint was triggered on code it shouldn't have
Description
Summary
I manually drop my MutexGuard right before the await point, therefore the lock is not held across await points.
Lint Name
await_holding_lock
Reproducer
I tried this code:
async fn test_clippy_mutex_await() { let mutex = std::sync::Mutex::new(()); let lock = mutex.lock().unwrap(); drop(lock); (async {}).await; }I saw this happen:
warning: this `MutexGuard` is held across an `await` point --> crates\symbolicator-cache\src\lib.rs:91:9 | 91 | let lock = mutex.lock().unwrap(); | ^^^^ | = help: consider using an async-aware `Mutex` type or ensuring the `MutexGuard` is dropped before calling await note: these are all the `await` points this lock is held through --> crates\symbolicator-cache\src\lib.rs:91:5 | 91 | / let lock = mutex.lock().unwrap(); 92 | | drop(lock); 93 | | 94 | | (async {}).await; 95 | | } | |_^ = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#await_holding_lock = note: `#[warn(clippy::await_holding_lock)]` on by default I expected to see this happen:
This should not error as the MutexGuard is not alive at the await point.
Version
rustc 1.66.0-nightly (dcb376115 2022-10-20) binary: rustc commit-hash: dcb376115066d111dbf5f13d5ac2a2dbe8c12add commit-date: 2022-10-20 host: x86_64-pc-windows-msvc release: 1.66.0-nightly LLVM version: 15.0.2 Additional Labels
No response
oxalica, ognevny and LennyLizowzskiy
Metadata
Metadata
Assignees
Labels
C-bugCategory: Clippy is not doing the correct thingCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't haveIssue: The lint was triggered on code it shouldn't have