rust/tests
bors 5aae5f6ae6 Auto merge of #12740 - lrh2000:sig-drop, r=blyxyas
`significant_drop_in_scrutinee`: Trigger lint only if lifetime allows early significant drop

I want to argue that the following code snippet should not trigger `significant_drop_in_scrutinee` (https://github.com/rust-lang/rust-clippy/issues/8987). The iterator holds a reference to the locked data, so it is expected that the mutex guard must be alive until the entire loop is finished.
```rust
use std::sync::Mutex;

fn main() {
    let mutex_vec = Mutex::new(vec![1, 2, 3]);
    for number in mutex_vec.lock().unwrap().iter() {
        dbg!(number);
    }
}
```

However, the lint should be triggered when we clone the vector. In this case, the iterator does not hold any reference to the locked data.
```diff
-     for number in mutex_vec.lock().unwrap().iter() {
+     for number in mutex_vec.lock().unwrap().clone().iter() {
```

Unfortunately, it seems that regions on the types of local variables are mostly erased (`ReErased`) in the late lint pass. So it is hard to tell if the final expression has a lifetime relevant to the value with a significant drop.

In this PR, I try to make a best-effort guess based on the function signatures. To avoid false positives, no lint is issued if the result is uncertain. I'm not sure if this is acceptable or not, so any comments are welcome.

Fixes https://github.com/rust-lang/rust-clippy/issues/8987

changelog: [`significant_drop_in_scrutinee`]: Trigger lint only if lifetime allows early significant drop.

r? `@flip1995`
2024-05-25 13:11:21 +00:00
..
test_utils
ui Auto merge of #12740 - lrh2000:sig-drop, r=blyxyas 2024-05-25 13:11:21 +00:00
ui-cargo
ui-internal
ui-toml Add configuration option for ignoring panic!() in tests 2024-05-16 05:45:56 +00:00
workspace_test
check-fmt.rs
clippy.toml
compile-test.rs
dogfood.rs
headers.rs
integration.rs
lint_message_convention.rs
missing-test-files.rs
versioncheck.rs
workspace.rs