`significant_drop_tightening` false positive with invalid code using `Mutex<HashMap>`

[Lynnesbian]

Summary

significant_drop_tightening suggests merging the lock acquisition into the HashMap::get, even though this would cause data to be dropped while borrowed. Additionally, the suggested code is missing the get call entirely, making it invalid even before the borrow check issue arises.

Lint Name

significant_drop_tightening

Reproducer

Playground link

I tried this code:

#![deny(clippy::significant_drop_tightening)]

use std::collections::HashMap;
use std::sync::Mutex;

fn main() {
    let map = Mutex::new(HashMap::from([(String::from("test"), String::new())]));
    let key = String::from("test");
    let lock = map.lock().unwrap();
    let data = lock.get(&key).expect("key should exist");
    println!("{data}")
}

I saw this happen:

    Checking playground v0.0.1 (/playground)
error: temporary with significant `Drop` can be early dropped
  --> src/main.rs:9:9
   |
 6 |   fn main() {
   |  ___________-
 7 | |     let map = Mutex::new(HashMap::from([(String::from("test"), String::new())]));
 8 | |     let key = String::from("test");
 9 | |     let lock = map.lock().unwrap();
   | |         ^^^^
10 | |     let data = lock.get(&key).expect("key should exist");
11 | |     println!("{data}")
12 | | }
   | |_- temporary `lock` is currently being dropped at the end of its contained scope
   |
   = note: this might lead to unnecessary resource contention
   = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#significant_drop_tightening
note: the lint level is defined here
  --> src/main.rs:1:9
   |
 1 | #![deny(clippy::significant_drop_tightening)]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: merge the temporary construction with its single usage
   |
 9 ~     
10 +     let data = map.lock().unwrap().expect("key should exist");
11 ~     
   |

error: could not compile `playground` (bin "playground") due to 1 previous error

I expected to see this happen: No suggestion

Version

rustc 1.100.0-beta.1 (e3feeb59c 2026-09-27)
binary: rustc
commit-hash: e3feeb59cd1bdd011a2bfcc0747b55125d9b8527
commit-date: 2026-09-27
host: x86_64-unknown-linux-gnu
release: 1.100.0-beta.1
LLVM version: 23.1.1

Additional Labels

@rustbot label + I-suggestion-causes-error

[rustbot]

Error: Parsing relabel command in comment failed: empty label when parsing: label +[!] I-suggest

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[mi2ebi]

@rustbot label +I-suggestion-causes-error