Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
thread name in stack overflow message
Fixesrust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628.
This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR.
This PR also amends the stack overflow test to check for thread names, so we don't run into this again.
``@rustbot`` label +beta-nominated
Guarantee 8 bytes of alignment in Thread::into_raw
When using `AtomicPtr` for synchronization it's incredibly useful when you've got a couple bits you can stuff metadata in. By guaranteeing that `Thread`'s `Inner` struct is aligned to 8 bytes everyone can use the bottom 3 bits to signal other things, such as a critical section, etc.
This guarantee is thus very useful and costs us nothing.
Using clock nanosleep leads to more accurate sleep times on platforms
where it is supported.
To enable using clock_nanosleep this makes `sleep_until` platform
specific. That unfortunatly requires identical placeholder
implementations for the other platforms (windows/mac/wasm etc).
we will land platform specific implementations for those later. See the
`sleep_until` tracking issue.
This requires an accessors for the Instant type. As that accessor is only
used on the platforms that have clock_nanosleep it is marked as allow_unused.
32bit time_t targets do not use clock_nanosleep atm, they instead rely
on the same placeholder as the other platforms. We could make them
use clock_nanosleep too in the future using `__clock_nanosleep_time64`.
__clock_nanosleep_time64 is documented at:
https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html
This allows these test modules to pass on builds/targets without
unwinding support, where `panic = "abort"` - the ignored tests are for
functionality that's not supported on those targets.
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
Return unexpected termination error instead of panicing in `Thread::join`
There is a time window during which the OS can terminate a thread before stdlib can retreive its `Packet`. Currently the `Thread::join` panics with no message in such an event, which makes debugging difficult; fixes#124466.
There is a time window during which the OS can terminate a thread before stdlib
can retreive its `Packet`. Currently the `Thread::join` panics with no message
in such an event, which makes debugging difficult; fixes#124466.
Thereby, we also allow accessing thread::current before main: as the runtime no longer tries to install its own handle, this will no longer trigger an abort. Rather, the name returned from name will only be "main" after the runtime initialization code has run, but I think that is acceptable.
This new approach also requires some changes to the signal handling code, as calling `thread::current` would now allocate when called on the main thread, which is not acceptable. I fixed this by adding a new function (`with_current_name`) that performs all the naming logic without allocation or without initializing the thread ID (which could allocate on some platforms).
There are multiple references in this module's documentation to the acronym "TLS", without defining it. This is confusing for the reader.
I propose that this acronym be defined during the first use of the term.
a release operation synchronizes with an acquire operation
Change:
1. `Calls to park _synchronize-with_ calls to unpark` to `Calls to unpark _synchronize-with_ calls to park`
2. `park synchronizes-with _all_ prior unpark operations` to `_all_ prior unpark operations synchronize-with park`
Bump boostrap compiler to new beta
Currently failing due to something about the const stability checks and `panic!`. I'm not sure why though since I wasn't able to see any PRs merged in the past few days that would result in a `cfg(bootstrap)` that shouldn't be removed. cc `@RalfJung` #131349
std: allow after-main use of synchronization primitives
By creating an unnamed thread handle when the actual one has already been destroyed, synchronization primitives using thread parking can be used even outside the Rust runtime.
This also fixes an inefficiency in the queue-based `RwLock`: if `thread::current` was not initialized yet, it will create a new handle on every parking attempt without initializing `thread::current`. The private `current_or_unnamed` function introduced here fixes this.
