From 75df635cb87b53f668f92d2a3545e25ee6000b95 Mon Sep 17 00:00:00 2001 From: Alex Crichton Date: Thu, 20 May 2021 12:45:05 -0700 Subject: [PATCH] std: Don't inline TLS accessor on MinGW This is causing [issues] on Cargo's own CI for MinGW and given the original investigation there's no reason that MinGW should work when MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception. [issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453 --- library/std/src/thread/local.rs | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/library/std/src/thread/local.rs b/library/std/src/thread/local.rs index c2c7ab918985b..e62f4440b369c 100644 --- a/library/std/src/thread/local.rs +++ b/library/std/src/thread/local.rs @@ -162,7 +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 + #[cfg_attr(not(windows), inline)] // see comments below unsafe fn __getit() -> $crate::option::Option<&'static $t> { const _REQUIRE_UNSTABLE: () = $crate::thread::require_unstable_const_init_thread_local(); @@ -262,28 +262,28 @@ macro_rules! __thread_local_inner { 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 + // everywhere other than Windows?", 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 + // this function is inlined. The longer story is that Windows 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 + // Because of this we never inline on Windows, 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" + // inline this function on Windows, 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. + // 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, Windows + // 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)] + // The issue of "should enable on Windows sometimes" is #84933 + #[cfg_attr(not(windows), inline)] unsafe fn __getit() -> $crate::option::Option<&'static $t> { #[cfg(all(target_arch = "wasm32", not(target_feature = "atomics")))] static __KEY: $crate::thread::__StaticLocalKeyInner<$t> =