Deadlock caused by lock not being released in this case.

[623637646]

I tried this code:

use std::sync::{Arc, Mutex};

fn main() {
    let lock = Arc::new(Mutex::new(Some(S)));
    let lock_cloned = lock.clone();

    {
        // This code works fine
        // let mut lock = lock.lock().unwrap();
        // lock.take()

        // This code deadlocks
        lock.lock().unwrap().take()
    }
    .unwrap()
    .foo(lock_cloned);

    println!("end")
}

struct S;

impl S {
    fn foo(self, lock: Arc<Mutex<Option<S>>>) {
        let _l = lock.lock().unwrap();
    }
}

I expected to see this happen: print end and the finish

Instead, this happened: deadlock

Meta

rustc --version --verbose:

rustc 1.88.0-nightly (934880f58 2025-04-09)
binary: rustc
commit-hash: 934880f586f6ac1f952c7090e2a943fcd7775e7b
commit-date: 2025-04-09
host: aarch64-apple-darwin
release: 1.88.0-nightly
LLVM version: 20.1.2

Backtrace

<backtrace>

[RalfJung]

This is expected behavior. Temporaries such as the return value of lock.lock() live until the end of the current statement, i.e., basically until the next ;. The Rust compiler does exactly what the documentation says it should do.

So, why do you think this is a bug in Rust?

[623637646]

{
  lock.lock().unwrap().take()
}

From my understanding, the lock should be released at the end of the scope ({}), since no variable holds it beyond that point.
It wouldn’t make sense for the lock to be released when a variable is used, but not released when no variable is used.

[RalfJung]

The temporaries of the tail expression of a block are dropped outside that block. Often, this is what you want, but in cases like this it can be surprising. Remember that the compiler has no understanding of what a lock is, it just inserts drop calls for the MutexGuard the same way it inserts drop calls for everything.

I'll close this since the compiler behaves as intended. We can always think about changing drop scope rules in a future edition, but that would be a major effort and require a lot of work before it can even reach the RFC stage.

It may be worth filing a lint suggestion with clippy to have clippy detect cases of MutexGuard being dropped late that are likely accidental.

[623637646]

Thanks for the clarification.

The temporaries of the tail expression of a block are dropped outside that block

Yes, I agree with this. The returned value of take() should be dropped outside the block. But the MutexGuard of lock.lock().unwrap() should be dropped inside the block. Correct me if I am wrong.

[RalfJung]

The current rules are that all temporaries of the entire tail expression (lock.lock().unwrap().take()) get dropped outside the block. As I said above, that's often what you want, but unfortunately not always -- but it's very hard to come up with easy rules that always do what you want...