Auto merge of #84876 - alexcrichton:inline-thread-locals-cross-crate, r=Mark-Simulacrum
std: Attempt again to inline thread-local-init across crates Issue #25088 has been part of `thread_local!` for quite some time now. Historical attempts have been made to add `#[inline]` to `__getit` in #43931, #50252, and #59720, but these attempts ended up not landing at the time due to segfaults on Windows. In the interim though with `const`-initialized thread locals AFAIK this is the only remaining bug which is why you might want to use `#[thread_local]` over `thread_local!`. As a result I figured it was time to resubmit this and see how it fares on CI and if I can help debugging any issues that crop up. Closes #25088
This commit is contained in:
commit
3bcaeb0bf9
3 changed files with 80 additions and 0 deletions
|
@ -162,6 +162,7 @@ macro_rules! thread_local {
|
|||
macro_rules! __thread_local_inner {
|
||||
// used to generate the `LocalKey` value for const-initialized thread locals
|
||||
(@key $t:ty, const $init:expr) => {{
|
||||
#[cfg_attr(not(target_env = "msvc"), inline)] // see comments below
|
||||
unsafe fn __getit() -> $crate::option::Option<&'static $t> {
|
||||
const _REQUIRE_UNSTABLE: () = $crate::thread::require_unstable_const_init_thread_local();
|
||||
|
||||
|
@ -260,6 +261,29 @@ macro_rules! __thread_local_inner {
|
|||
#[inline]
|
||||
fn __init() -> $t { $init }
|
||||
|
||||
// When reading this function you might ask "why is this inlined
|
||||
// everywhere other than MSVC?", and that's a very reasonable
|
||||
// question to ask. The short story is that it segfaults rustc if
|
||||
// this function is inlined. The longer story is that MSVC looks to
|
||||
// not support `extern` references to thread locals across DLL
|
||||
// boundaries. This appears to at least not be supported in the ABI
|
||||
// that LLVM implements.
|
||||
//
|
||||
// Because of this we never inline on MVSC, but we do inline on
|
||||
// other platforms (where external references to thread locals
|
||||
// across DLLs are supported). A better fix for this would be to
|
||||
// inline this function on MSVC, but only for "statically linked"
|
||||
// components. For example if two separately compiled rlibs end up
|
||||
// getting linked into a DLL then it's fine to inline this function
|
||||
// across that boundary. It's only not fine to inline this function
|
||||
// across a DLL boundary. Unfortunately rustc doesn't currently have
|
||||
// this sort of logic available in an attribute, and it's not clear
|
||||
// that rustc is even equipped to answer this (it's more of a Cargo
|
||||
// question kinda). This means that, unfortunately, MSVC gets the
|
||||
// pessimistic path for now where it's never inlined.
|
||||
//
|
||||
// The issue of "should enable on MSVC sometimes" is #84933
|
||||
#[cfg_attr(not(target_env = "msvc"), inline)]
|
||||
unsafe fn __getit() -> $crate::option::Option<&'static $t> {
|
||||
#[cfg(all(target_arch = "wasm32", not(target_feature = "atomics")))]
|
||||
static __KEY: $crate::thread::__StaticLocalKeyInner<$t> =
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue