-
Notifications
You must be signed in to change notification settings - Fork 13.4k
std: Tweak expansion of thread-local const #90774
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: rust-lang#84223 (comment)
514730e
to
1ac5d7d
Compare
@@ -165,6 +165,7 @@ macro_rules! __thread_local_inner { | |||
#[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(); | |||
const INIT_EXPR: $t = $init; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably INIT_VAL
would be better, since it isn't an expression.
@bors r+ |
📌 Commit 1ac5d7d has been approved by |
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: rust-lang#84223 (comment)
std: Tweak expansion of thread-local const This commit tweaks the expansion of `thread_local!` when combined with a `const { ... }` value to help ensure that the rules which apply to `const { ... }` blocks will be the same as when they're stabilized. Previously with this invocation: thread_local!(static NAME: Type = const { init_expr }); this would generate (on supporting platforms): #[thread_local] static NAME: Type = init_expr; instead the macro now expands to: const INIT_EXPR: Type = init_expr; #[thread_local] static NAME: Type = INIT_EXPR; with the hope that because `init_expr` is defined as a `const` item then it's not accidentally allowing more behavior than if it were put into a `static`. For example on the stabilization issue [this example][ex] now gives the same error both ways. [ex]: rust-lang#84223 (comment)
Could this have caused the following aarch64 assertion failure in the rollup #90975 CI (CI log):
apparently stemming from:
rust/library/std/src/sys_common/thread_info.rs Lines 41 to 47 in 1149193
|
@bors: r- That seems likely, yes, I will work on investigating. |
@bors: r=m-ou-se rollup=never Hm ok so I can't reproduce this locally and the IR looks the same before/after this change, so I'm going to put this back in the queue, but I'll exclude it from rollups in case it's still the culprit. |
📌 Commit 1ac5d7d has been approved by |
⌛ Testing commit 1ac5d7d with merge 66fdedc993e987dce337cbd88324cff0b3488559... |
💥 Test timed out |
It looks like dist-aarch64-apple took over an hour to rebuild LLVM, so presumably caches were being primed. @bors: retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (548c108): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
This commit tweaks the expansion of
thread_local!
when combined with aconst { ... }
value to help ensure that the rules which apply toconst { ... }
blocks will be the same as when they're stabilized.Previously with this invocation:
this would generate (on supporting platforms):
instead the macro now expands to:
with the hope that because
init_expr
is defined as aconst
item thenit's not accidentally allowing more behavior than if it were put into a
static
. For example on the stabilization issue this example nowgives the same error both ways.