Skip to content

False-positive await_holding_lock with manual drop of MutexGuard #9683

@Swatinem

Description

@Swatinem

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: Clippy is not doing the correct thingI-false-positiveIssue: The lint was triggered on code it shouldn't have

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions