`significant_drop_tightening` recommends dropping a lock in the middle of a loop

Summary

The output for significant_drop_tightening recommends dropping a lock in the middle of a loop, even if that lock is used in a subsequent iteration.

If there is only one access to the lock in the loop body, it recommends locking it at the use site, which might not be correct.

Lint Name

significant_drop_tightening

Reproducer

I tried this code:

use std::sync::Mutex;

let mutex = Mutex::new(0);
    
let mut lock = mutex.lock().unwrap();
for x in 0..100 {
    let n = *lock;
    *lock += x;
    println!("n = {n}");
}

I saw this happen:

warning: temporary with significant `Drop` can be early dropped
  --> src\main.rs:6:13
   |
3  |   fn main() {
   |  ___________-
4  | |     let mutex = Mutex::new(0);
5  | |
6  | |     let mut lock = mutex.lock().unwrap();
   | |             ^^^^
...  |
11 | |     }
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/master/index.html#significant_drop_tightening
   = note: requested on the command line with `-W clippy::significant-drop-tightening`
help: drop the temporary after the end of its last usage
   |
9  ~         *lock += x;
10 +         drop(lock);
   |

I expected to see this happen:

Lint triggered after the end of the loop, if it is triggered at all.

Version

rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-pc-windows-msvc
release: 1.75.0
LLVM version: 17.0.6

and

rustc 1.77.0-nightly (e51e98dde 2023-12-31)
binary: rustc
commit-hash: e51e98dde6a60637b6a71b8105245b629ac3fe77
commit-date: 2023-12-31
host: x86_64-pc-windows-msvc
release: 1.77.0-nightly
LLVM version: 17.0.6

Additional Labels

No response

Start by reproducing the significant_drop_tightening warning with the Rust code in the issue, then locate the lint implementation and its existing tests in rust-clippy. Trace how lock uses inside loops are identified. Done means the reproducer no longer receives an incorrect mid-loop drop suggestion and regression coverage captures the expected behavior.