kmc-solid: Fix memory ordering in thread operations
Fixes two memory ordering issues in the thread state machine (`ThreadInner::lifecycle`) of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
1. When detaching a thread that is still running (i.e., the owner updates `lifecycle` first, and the child updates it next), the first update did not synchronize-with the second update, resulting in a data race between the first update and the deallocation of `ThreadInner` by the child thread.
2. When joining on a thread, the joiner has to pass its own task ID to the joinee in order to be woken up later, but in doing so, it did not synchronize-with the read operation, creating possible sequences of execution where the joinee wakes up an incorrect or non-existent task.
Both issue are theoretical and most likely have never manifested in practice because of the stronger guarantees provided by the Arm memory model (particularly due to its barrier-based definition). Compiler optimizations could have subverted this, but the inspection of compiled code did not reveal such optimizations taking place.
Bump master bootstrap compiler
This PR bumps the bootstrap compiler to the beta created earlier this week, cherry-picks the stabilization version number updates, and updates the `cfg(bootstrap)`s.
r? `@Mark-Simulacrum`
adjust message on non-unwinding panic
"thread panicked while panicking" is just plain wrong in case this is a non-unwinding panic, such as
- a panic out of a `nounwind` function
- the sanity checks we have in `mem::uninitialized` and `mem::zeroed`
- the optional debug assertion in various unsafe std library functions
Clarify `catch_unwind` docs about panic hooks
Makes it clear from `catch_unwind` docs that the panic hook will be called before the panic is caught.
Fixes#105432
Make sentinel value configurable in `library/std/src/sys_common/thread_local_key.rs`
This is an excerpt of a changeset for the QNX/Neutrino OS. To make the patch for QNX smaller and easier to review, I've extracted this change (which is OS independent). I would be surprised if no other OS is also affected.
All this patch does is to define a `const` for a sentinel value instead of using it directly at several places.
There are OSs that always return the lowest free value. The algorithm in `lazy_init` always avoids keys with the sentinel value.
In affected OSs, this means that each call to `lazy_init` will always request two keys from the OS and returns/frees the first one (with sentinel value) immediately afterwards.
By making the sentinel value configurable, affected OSs can use a different value than zero to prevent this performance issue.
On QNX/Neutrino, it is planned to use a different sentinel value:
```rust
// Define a sentinel value that is unlikely to be returned
// as a TLS key (but it may be returned).
#[cfg(not(target_os = "nto"))]
const KEY_SENTVAL: usize = 0;
// On QNX/Neutrino, 0 is always returned when currently not in use.
// Using 0 would mean to always create two keys and remote the first
// one (with value of 0) immediately afterwards.
#[cfg(target_os = "nto")]
const KEY_SENTVAL: usize = libc::PTHREAD_KEYS_MAX + 1;
```
It seems like no other OS defines `PTHREAD_KEYS_MAX` in Rusts libc, but `limits.h` on unix systems does.
available_parallelism: Gracefully handle zero value cfs_period_us
There seem to be some scenarios where the cgroup cpu quota field `cpu.cfs_period_us` can contain `0`. This field is used to determine the "amount" of parallelism suggested by the function `std:🧵:available_parallelism`
A zero value of this field cause a panic when `available_parallelism()` is invoked. This issue was detected by the call from binaries built by `cargo test`. I really don't feel like `0` is a good value for `cpu.cfs_period_us`, but I also don't think applications should panic if this value is seen.
This panic started happening with rust 1.64.0.
This case is gracefully handled by other projects which read this information: [num_cpus](e437b9d908/src/linux.rs (L207-L210)), [ninja](https://github.com/ninja-build/ninja/pull/2174/files), [dotnet](c4341d45ac/src/coreclr/pal/src/misc/cgroup.cpp (L481-L483))
Before this change, running `cargo test` in environments configured as described above would trigger this panic:
```
$ RUST_BACKTRACE=1 cargo test
Finished test [unoptimized + debuginfo] target(s) in 3.55s
Running unittests src/main.rs (target/debug/deps/x-9a42e145aca2934d)
thread 'main' panicked at 'attempt to divide by zero', library/std/src/sys/unix/thread.rs:546:70
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::panicking::panic
3: std::sys::unix:🧵:cgroups::quota
4: std::sys::unix:🧵:available_parallelism
5: std:🧵:available_parallelism
6: test::helpers::concurrency::get_concurrency
7: test::console::run_tests_console
8: test::test_main
9: test::test_main_static
10: x::main
at ./src/main.rs:1:1
11: core::ops::function::FnOnce::call_once
at /tmp/rust-1.64-1.64.0-1/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: test failed, to rerun pass '--bin x'
```
I've tested this change in an environment which has the bad (questionable?) setup and rebuilding the test executable against a fixed std library fixes the panic.
Move `ReentrantMutex` to `std::sync`
If I understand #84187 correctly, `sys_common` should not contain platform-independent code, even if it is private.
Implement allow-by-default `multiple_supertrait_upcastable` lint
The lint detects when an object-safe trait has multiple supertraits.
Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them.
r? `@nikomatsakis`
Fix backoff doc to match implementation
The commit 8dddb22943 in the crossbeam-channel PR (#93563) changed the backoff strategy to be quadratic instead of exponential. This updates the doc to prevent confusion.
Test leaking of BinaryHeap Drain iterators
Add test cases about forgetting the `BinaryHeap::Drain` iterator, and slightly fortifies some other test cases.
Consists of separate commits that I don't think are relevant on their own (but I'll happily turn these into more PRs if desired).
Clarify docs of `RefCell`
Comparison operators only panic if the `RefCell` is mutably borrowed, and `RefCell::swap()` can also panic if swapping a `RefCell` with itself.
Use correct clock in `park_timeout` on Horizon
Horizon does not support using `CLOCK_MONOTONIC` with condition variables, so use the system time instead.
Fix UnsafeCell Documentation Spelling Error
This fixes the spelling of "deallocated" (instead of the original "deallocted") In the `cell.rs` source file. Honestly probably not worth the time to evaluate, but since it doesn't involve any code change, I figure why not?
Update the documentation of `Vec` to use `extend(array)` instead of `extend(array.iter().copied())`
Another option is to use `extend_from_slice()` (that may be faster), but I find this approach cleaner.
Fix a formatting error in Iterator::for_each docs
There is a formatting error (extra space in an assignment) in the documentation of `core::iter::Iterator::for_each`, which I have fixed in this pull request.
More inference-friendly API for lazy
The signature for new was
```
fn new<F>(f: F) -> Lazy<T, F>
```
Notably, with `F` unconstrained, `T` can be literally anything, and just `let _ = Lazy::new(|| 92)` would not typecheck.
This historiacally was a necessity -- `new` is a `const` function, it couldn't have any bounds. Today though, we can move `new` under the `F: FnOnce() -> T` bound, which gives the compiler enough data to infer the type of T from closure.
abort immediately on bad mem::zeroed/uninit
Now that we have non-unwinding panics, let's use them for these assertions. This re-establishes the property that `mem::uninitialized` and `mem::zeroed` will never unwind -- the earlier approach of causing panics here sometimes led to hard-to-debug segfaults when the surrounding code was not able to cope with the unexpected unwinding.
Cc `@bjorn3` I did not touch cranelift but I assume it needs a similar patch. However it has a `codegen_panic` abstraction that I did not want to touch since I didn't know how else it is used.
add ptr::from_{ref,mut}
We have methods to avoid almost all `as` casts around raw pointer handling, except for the initial cast from reference to raw pointer. These new methods close that gap.
(I also moved `null_mut` next to `null` to keep the file consistently organized.)
r? libs-api
Tracking issue: https://github.com/rust-lang/rust/issues/106116
Rollup of 6 pull requests
Successful merges:
- #105465 (Improve top-level docs)
- #105872 (Suggest remove last method call when type coerce with expected type)
- #106032 (std: only use LFS function on glibc)
- #106078 (Provide more context on FileCheck failures)
- #106100 (Codegen test for derived `<` on trivial newtype [TEST ONLY])
- #106109 (rustdoc: make line number CSS for doc comment and scraped the same)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
char: µoptimise UTF-16 surrogates decoding
According to Godbolt¹, on x86_64 using binary and produces slightly
better code than using subtraction. Readability of both is pretty
much equivalent so might just as well use the shorter option.
¹ https://rust.godbolt.org/z/9jM3ejbMx
