Added unlock functionality to mutex guard and rw lock guards

[SpaceBroetchen]

Added unlock functionality for nonpoison mutex guards and RwLock guards.

Associated Tracking Issue: #148568

[rustbot]

r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[y21]

Not a fundamental design issue, but the implementation looks unsound in the presence of panics since it leaves the Mutex unlocked when exiting the function

let mutex = Mutex::new(1);
let mut guard = mutex.lock().unwrap();
panic::catch_unwind(AssertUnwindSafe(|| MutexGuard::unlocked(&mut guard, || panic!())));

let ref1 = &mut *guard;
let ref2 = &mut *mutex.lock();
dbg!(ref1, ref2);

lock_api doesn't have this issue since it calls lock() in a local's Drop impl that always executes, should probably do the same here.

edit: Ah, I overlooked the new unlocked: bool field, the comment for it also talks about panicking in the closure, but from a cursory look I'm not sure it prevents this issue?

[joboet]

Oh yes, that's unsound. I don't think the "no relock during panic" guarantee can be soundly provided, at least if unlocked only takes the mutex guard by reference.

[joboet]

How important is this guarantee? I find it unfortunate that this necessitates adding a field and an additional check in the Drop implementation, which affects all code using MutexGuards, not just code that calls unlocked.

[ChrisDenton]

r? joboet

[rust-bors]

☔ The latest upstream changes (presumably #154815) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC]

@SpaceBroetchen any updates on this? thanks