Tracking Issue for const-initialized thread locals

[alexcrichton]

Feature gate: #![feature(thread_local_const_init)]

This is a tracking issue for the const-initialization of thread locals in the standard library added in #83416.

Public API

use std::cell::Cell;
std::thread_local!(static KEY: Cell<u32> = const { Cell::new(0) });

// ... same APIs as before with thread locals

The API here is intended to be exclusively within the syntax of the preexisting thread_local! macro. The initialization expression for thread local keys can now be surrounded with const { ... } to indicate that the value should be const-evaluated and initialized.

Note that this also supports the multi-definition form:

use std::cell::Cell;
std::thread_local! {
    static KEY1: Cell<u32> = const { Cell::new(0) };
    static KEY2: Cell<u32> = const { Cell::new(0) };
}

Steps / History

• Implementation: std: Add a variant of thread locals with const init #83416
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• Syntax bikeshed - is the use of what is likely to be a future-feature, const blocks, ok here? Are there other options for syntax?

[alexcrichton]

I've requested this be tagged I-nominated for discussion for stabilization, but I figured I'd want to paste some background here as well. My personal main motivation for this is optimizing the pieces of Wasmtime where a host calls into a WebAssembly module. Part of that is frobbing some TLS values as we enter into wasm, and this frobbing is actually marked #[inline(never)] for the poor cross-crate codegen that TLS has otherwise. This outlining plus the extra checks for whether or not TLS is initialized is what I'm trying to optimize.

In benchmarks locally the call overhead of host->wasm decreases from 20ns to 18ns (10% reduction) with the usage of const-initialized-thread-locals (which are also #[inline]'d since they have good codegen). This isn't really gonna make or break anyone's day since it's a pretty small difference, but nevertheless I'd love to get it out of the way so I don't have to worry about it again.

Another data point I see linked here is that rustc is using const-initialized thread locals for some moderate gains across the board.

There was some brief discussion on Zulip about the syntax when I originally asked to stabilize. One thing I'll clarify is that this doesn't literally use const { .. } blocks in the expanded code, the macro is simply recognizing it as input syntax. I believe one gotcha of this is that if you have $e:expr in a macro and in the future $e is something like const { 1 } I don't think that it will use the const-initialized version of thread_local! were you to do something like thread_local!(static X: i32 = $e) since I don't think that rustc splits apart tokens to match sub-patterns in a macro. This will, however, work for literal declarations like thread_local!(static X: i32 = const { 1 });

Overall the biggest thing to decide here I think is the syntax. One alternative is a whole new macro, but I think that it'd be ideal if we could keep it in one macro to not have to worry about multiple. Otherwise though I'm happy to implement whatever syntax.

[m-ou-se]

Discussed in the library api team meeting. We'd like @rust-lang/lang to sign off on this.

[nikomatsakis]

This seems like a fine thing to stabilize; however, just to be clear, is this feature any use without const blocks? I guess that one can still stabilize to other constants (e.g., simple integer values)?

[alexcrichton]

This doesn't actually use const { .. } blocks at the compiler level, it's basically just surface syntax to the macro itself. In that sense this should still be useful even if Rust never gets const { .. } blocks because it would still trigger the specialized implementation for this macro where the initialization expression is a constant known at compile time

[cramertj]

It seems a little funky to me to stabilize a syntax that, at a surface level, matches that of a pre-existing unstable feature (const blocks). Even though it may not require const blocks under the hood, in the long-term I think users would expect that the set of things allowed inside thread_local!(static X: Y = const { <code here> }; would match the rules for what could be present in static X: Y = const { ... };.

That is, if we decided that some surface syntax or semantics should be different inside const blocks, I'd also want it to be different in these not-const-blocks. Are we confident that we'll be able to provide matching semantics in each of these contexts in the future? That is, that the not-const-block in thread_local! doesn't allow anything that a const block wouldn't allow?

[nikomatsakis]

Oh, wait, maybe I misunderstood. I didn't realize that const { ... } was part of the macro, I expected it to accept "any expression". That said, I'll have to review, but I would expect that indeed it should accept the same set of code?