Skip to content

False positive significant_drop_in_scrutinee if matching on a MutexGuard even if it is still used afterwards #9072

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sdroege opened this issue Jun 30, 2022 · 2 comments · Fixed by #12764
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have

Comments

@sdroege
Copy link

sdroege commented Jun 30, 2022

Summary

See reproducer below

Lint Name

significant_drop_in_scrutinee

Reproducer

I tried this code:

fn main() {
    let x = std::sync::Mutex::new(vec![1, 2, 3]);
    let x_guard = x.lock().unwrap();
    match x_guard[0] {
        1 => println!("1!"),
        x => println!("{x}"),
    }
    drop(x_guard); // Some "usage"
}

I saw this happen:

warning: temporary with significant drop in match scrutinee
 --> src/main.rs:4:11
  |
4 |     match x_guard[0] {
  |           ^^^^^^^^^^
  |
  = note: `#[warn(clippy::significant_drop_in_scrutinee)]` on by default
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#significant_drop_in_scrutinee
help: try moving the temporary above the match
  |
4 ~     let value = x_guard[0];
5 ~     match value {
  |

I expected to see this happen: No warning

Version

rustc 1.63.0-beta.2 (6c1f14289 2022-06-28)
binary: rustc
commit-hash: 6c1f1428998a08864495bb599840a5997ec175f4
commit-date: 2022-06-28
host: x86_64-unknown-linux-gnu
release: 1.63.0-beta.2
LLVM version: 14.0.5

Additional Labels

@rustbot label +I-false-positive

@sdroege sdroege added C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have labels Jun 30, 2022
@sdroege
Copy link
Author

sdroege commented Jun 30, 2022

Arguably even without the later usage this shouldn't produce a warning because the MutexGuard is not only temporary during the match but outlives it.

bors added a commit that referenced this issue Aug 8, 2022
Move `significant_drop_in_scrutinee` into `nursey`

The current suggestion of extending the lifetime of every sub-expression is not great and doesn't fix the error given in the lint's example, though it does make the potential deadlock easier to see, but it can also cause it's own issues by delaying the drop of the lock guard.

e.g.
```rust
match x.lock().foo {
    ..
}
// some stuff
let y = x.lock();
```
The suggestion would create a deadlock at the second `x.lock()` call.

This also lints even when a significant drop type isn't created as a temporary. (#9072)

I agree `@kpreid` (#8987 (comment)) that this should be back-ported before the lint hits stable.

changelog: Move `significant_drop_in_scrutinee` into `nursey`
@fxdave
Copy link

fxdave commented Dec 9, 2022

Here it is another example:

let mut db = db.lock().unwrap();
match db.remove(&path.0) {
    Ok(removed) => HttpResponse::Ok().json(DeleteSuccessResponse { removed }),
    Err(error) => HttpResponse::InternalServerError().json(GenericError {
        error: error.to_string(),
    }),
}

However, the fix was easy in this case:

let mut db = db.lock().unwrap();
+ let result = db.remove(&path.0);
+ match result {
- match db.remove(&path.0) {
    Ok(removed) => HttpResponse::Ok().json(DeleteSuccessResponse { removed }),
    Err(error) => HttpResponse::InternalServerError().json(GenericError {
        error: error.to_string(),
    }),
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have
Projects
None yet
2 participants