rust/library/std/src/sys/thread_local, branch beta

library: Migrate from `cfg_if` to `cfg_select`

2025-08-16T12:28:31+00:00

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.

Fix broken TLS destructors on 32-bit win7

2025-07-21T11:11:47+00:00

On the 32-bit win7 target, we use OS TLS instead of native TLS, due to issues with how the OS handles alignment. Unfortunately, this caused issues due to the TLS destructors not running, causing memory leaks among other problems. On Windows, to support OS TLS, the TlsAlloc family of function is used by Rust. This function does not support TLS destructors at all. However, rust has some code to emulate those destructors, by leveraging the TLS support functionality found in the MSVC CRT (specifically, in tlssup.c of the CRT). Specifically, the CRT provides the ability to register callbacks that are called (among other things) on thread destruction. By registering our own callback, we can run through a list of registered destructors functions to execute. To use this functionality, the user must do two things: 1. They must put the address to their callback in a section between `.CRT$XLB` and `.CRT$XLY`. 2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to make sure the TLS support code in tlssup.c isn't garbage collected by the linker. Prior to this commit, this second bit wasn't being done properly by the Rust TLS support code. Instead of adding a reference to _tls_used, it instead had a reference to its own callback to prevent it from getting GC'd by the linker. While this is _also_ necessary, not having a reference on _tls_used made the entire support non-functional. This commit reworks the code to: 1. Add an unconditional `#[used]` attribute on the CALLBACK, which should be enough to prevent it from getting GC'd by the linker. 2. Add a reference to `_tls_used`, which should pull the TLS support code into the Rust programs and not let it be GC'd by the linker.

Rollup merge of #141455 - joboet:tls_exhaustion_abort, r=tgross35

2025-06-03T19:53:36+00:00

std: abort the process on failure to allocate a TLS key The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see https://github.com/rust-lang/rust/issues/140798#issuecomment-2872307377). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.

Address review comments.

2025-05-30T10:14:27+00:00

When replacing an old value we may not drop it in place

2025-05-28T15:53:14+00:00

Add same unsafe bound on get_or_init_slow

2025-05-28T15:10:50+00:00

Do not panic, maintain old behavior

2025-05-28T14:56:26+00:00

Improve safety comment, double-drop is not relevant here

2025-05-28T12:51:52+00:00

Do not move thread-locals before dropping

2025-05-28T12:39:51+00:00

std: abort the process on failure to allocate a TLS key

2025-05-23T16:00:09+00:00

The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see https://github.com/rust-lang/rust/issues/140798#issuecomment-2872307377). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.