`let_underscore_lock` fails on tuples

[bkstein]

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