let_underscore_lock fails on tuples #12356
Description
Summary
In case of a lock() function returning multiple locks, the lint may assert though the code behaves as intended. E.g.
struct Broker {...}; impl Broker { pub fn lock() -> Result<( MutexGuard<'static, Broker>, MutexGuard<'static, Store>, )> { let broker = BROKER_DATA.lock()?; let store = STORE_DATA.lock()?; Ok((broker, store)) } ... }will be used as e.g.
let (broker, _) = Broker::lock()?;Dropping of the second lock is obviously intended, if locks are used this way.
Footnote: it's probably unusual to return multiple locks and I'm not sure, if it's good practise anyway. The locks should better be combined to a third Mutex, but that's not the point of this issue.
Lint Name
let_underscore_lock
Reproducer
Using the above mentioned code, I saw this happen:
error: non-binding let on a synchronization lock --> ised/src/broker.rs:982:18 | 982 | let (broker, _) = &Broker::lock()?; | ^ this lock is not assigned to a binding and is immediately dropped | = help: consider immediately dropping the value using `drop(..)` after the `let` statement = note: `#[deny(let_underscore_lock)]` on by default help: consider binding to an unused variable to avoid immediately dropping the value | 982 | let (broker, _unused) = &Broker::lock()?; | ~~~~~~~ I expected to see this happen:
No error
Version
rustc 1.78.0-nightly (2bf78d12d 2024-02-18) binary: rustc commit-hash: 2bf78d12d33ae02d10010309a0d85dd04e7cff72 commit-date: 2024-02-18 host: x86_64-unknown-linux-gnu release: 1.78.0-nightly LLVM version: 18.1.0 Additional Labels
No response