Use const initialized thread locals where possible

[a1phyr]

Motivation

This PR uses a new feature (stabilized in Rust 1.59) to initialize some thread-local statics at compile time. This should bring better performances and code size.

Drawbacks

It adds back a build script to check the version of rustc.

[Noah-Kennedy]

I'm not entirely sure how I feel about this approach to getting by our MSRV. @Darksonn @hawkw thoughts?

[Darksonn]

I think we have done something similar in the past for #[track_caller].

[hawkw]

Yeah, we've done similar things in the past, so I'm fine with introducing the build script again provided that the benefit outweighs the extra complexity.

[Darksonn]

This looks good to me.

[caldwell]

I'm getting an error with tokio 1.20.0 on nightly-aarch64-apple-darwin updated - rustc 1.64.0-nightly (7fe022f5a 2022-07-24):

error[E0658]: use of unstable library feature 'thread_local_const_init'
  --> /Users/david/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/tokio-1.20.0/src/coop.rs:34:1
   |
34 | / thread_local! {
35 | |     static CURRENT: Cell<Budget> = const { Cell::new(Budget::unconstrained()) };
36 | | }
   | |_^
   |
   = note: see issue #84223 <https://github.com/rust-lang/rust/issues/84223> for more information
   = help: add `#![feature(thread_local_const_init)]` to the crate attributes to enable
   = note: this error originates in the macro `$crate::__thread_local_inner` (in Nightly builds, run with -Z macro-backtrace for more info)

This looks related to this change. Is this something I'm doing wrong, or is this a Tokio bug?

[Darksonn]

@caldwell The thread_local_const_init feature was stabilized in rustc 1.59.0, so it seems very weird that you would get such an error on a nightly newer than 1.59.0.

[Darksonn]

Does this compile for you?

thread_local! {
    static FOO: usize = const { 10 };
}

fn main() {
    println!("Hello, world!");
}

[caldwell]

Sigh, this was operator error: I had run rustup update but it merely downloaded a new compiler but didn't activate it like I expected. I was actually running 1.58 from December. With the latest nightly (2022-07-24) it builds just fine.

Thanks for your response and sorry about the bug spam!

[Darksonn]

Can you elaborate on how you were running it? Tokio should detect that you are on 1.58.0 and avoid using the feature. I just tried compiling with 1.58.0 myself and it worked fine.

[caldwell]

It was just cargo build, where tokio was a dependency. It also happened on a cargo install pijul (which is basically the same thing). The specific version(s) I was running:

$ rustc --version
rustc 1.59.0-nightly (532d2b14c 2021-12-03)
$ cargo version
cargo 1.58.0-nightly (294967c53 2021-11-29)

(I don't understand how those could be different.)

[Darksonn]

@caldwell I figured out what issue you ran into. See #4860 for the fix.

[caldwell]

Thanks, I appreciate your help!