rust/library/std/src/sync/mutex.rs, branch 1.68.2

std: remove lock wrappers in `sys_common`

2022-11-06T14:32:59+00:00

Rollup merge of #97739 - a2aaron:let_underscore, r=estebank

2022-09-02T09:34:45+00:00

Uplift the `let_underscore` lints from clippy into rustc. This PR resolves #97241. This PR adds three lints from clippy--`let_underscore_drop`, `let_underscore_lock`, and `let_underscore_must_use`, which are meant to capture likely-incorrect uses of `let _ = ...` bindings (in particular, doing this on a type with a non-trivial `Drop` causes the `Drop` to occur immediately, instead of at the end of the scope. For a type like `MutexGuard`, this effectively releases the lock immediately, which is almost certainly the wrong behavior) In porting the lints from clippy I had to copy over a bunch of utility functions from `clippy_util` that these lints also relied upon. Is that the right approach? Note that I've set the `must_use` and `drop` lints to Allow by default and set `lock` to Deny by default (this matches the same settings that clippy has). In talking with `@estebank` he informed me to do a Crater run (I am not sure what type of Crater run to request here--I think it's just "check only"?) On the linked issue, there's some discussion about using `must_use` and `Drop` together as a heuristic for when to warn--I did not implement this yet. r? `@estebank`

Auto merge of #97791 - m-ou-se:const-locks, r=m-ou-se

2022-06-19T08:20:36+00:00

Make {Mutex, Condvar, RwLock}::new() const. This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉 Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035), [on Windows](https://github.com/rust-lang/rust/pull/77380), and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647, the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const. Tracking issue: https://github.com/rust-lang/rust/issues/93740

Avoid `thread::panicking()` in non-poisoning methods of `Mutex` and `RwLock`

2022-06-09T18:51:39+00:00

`Mutex::lock()` and `RwLock::write()` are poison-guarded against panics, in that they set the poison flag if a panic occurs while they're locked. But if we're already in a panic (`thread::panicking()`), they leave the poison flag alone. That check is a bit of a waste for methods that never set the poison flag though, namely `get_mut()`, `into_inner()`, and `RwLock::read()`. These use-cases are now split to avoid that unnecessary call.

Update library/std/src/sync/mutex.rs

2022-06-07T13:15:19+00:00

Co-authored-by: Weiyi Wang

Remove confusing sentence from `Mutex` docs

2022-06-07T07:53:44+00:00

The docs were saying something about "statically initializing" the mutex, and it's not clear what this means. Remove that part to avoid confusion.

Make {Mutex, Condvar, RwLock}::new() const.

2022-06-06T11:55:43+00:00

Make all {Mutex, Condvar, RwLock}::new #[inline].

2022-06-06T11:49:23+00:00

Add diagnostic items to MutexGuard and RwLock Guards

2022-06-05T05:01:54+00:00

I forgot to add the diagnostic to the actual types in `std` earlier.

Auto merge of #96422 - tmccombs:mutex-unpoison, r=m-ou-se

2022-05-20T08:06:56+00:00

Add functions to un-poison Mutex and RwLock See discussion at https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521/3