Make the LocalKey facade of thread_local! inlineable cross-crate.

[eddyb]

Fixes (almost*) #25088 by changing the LocalKeystaticthread_local! generates to a const.
This can be done because a LocalKey value holds no actual TLS data, only function pointers to get at said data, and it could even be made Copy without any negative consequences.
The recent stabilization of rvalue promotion to 'static allows doing this without changing the API.
r? @alexcrichton

*almost because we can't yet inline __getit because it breaks on MSVC, see #43931 (comment)

[oli-obk]

This doesn't work on stage0 apparently.

[eddyb]

@oli-obk Fixing.

[alexcrichton]

Awesome, looks great!

One thing I noticed locally was that the __init function isn't inlined. Do you think it'd be worth it to do that? It's definitely overkill for expensive cases but maybe worth it for enough cases to go ahead and inline it as well?

Regardless of that decision r=me, just wanted to see what you thought

[eddyb]

Ah I didn't think much about it but in the cheap cases it'd definitely help.

@bors r=alexcrichton

[bors]

📌 Commit ee1a970 has been approved by alexcrichton

[bors]

⌛ Testing commit ee1a970513d32d8a748e446d10b093f6d79225ea with merge 414b93e932ec81413dddc3d011c8f0a3f5a6145c...

[bors]

💔 Test failed - status-appveyor

[kennytm]

@bors retry

Failed to build rustdoc because rustc failed to execute with error 3221225477, which is 0xc0000005 i.e. STATUS_ACCESS_VIOLATION. Assuming spurious for now.

Building rustdoc for stage2 (x86_64-pc-windows-msvc)
error: failed to run `rustc` to learn about target-specific information
Caused by:
process didn't exit successfully: `C:\projects\rust\build\bootstrap/debug/rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --target x86_64-pc-windows-msvc` (exit code: 3221225477)
command did not execute successfully: "C:\\projects\\rust\\build\\x86_64-pc-windows-msvc\\stage0/bin\\cargo.exe" "build" "-j" "2" "--target" "x86_64-pc-windows-msvc" "--release" "--locked" "--color" "always" "--manifest-path" "C:\\projects\\rust\\src/tools\\rustdoc\\Cargo.toml"

[bors]

⌛ Testing commit ee1a970513d32d8a748e446d10b093f6d79225ea with merge b60970f3ff1d0716c7ff153db0412ce677ea0e9b...

[bors]

💔 Test failed - status-appveyor

[kennytm]

Same issue. Legit. @eddyb

[eddyb]

Same failure. I have nofew ideas why this would happen, probably some pre-exiting bug I triggered.

[kennytm]

Perhaps a bug in the rvalue promotion to 'static on x86_64-pc-windows-msvc?

[eddyb]

@kennytm That const is just a facade, I expect OS TLS is broken cross-crate, or at least only in some subtle situations. Plus, rvalue promotion has been around since 1.0, in both old trans and the MIR one, and while there has been a known bug in the old trans implementation, it's pretty solid.

[eddyb]

(please do not r+) Going to try some builds without fast TLS, to see if the problem is even reproducible on other platforms - as windows would be a massive pain to debug (and the bug triggers in rustc).

EDIT: I'm dumb, MSVC doesn't use OS TLS, so it's the fast TLS that's broken...

[eddyb]

@alexcrichton Weren't there some oddities ages ago, back in the old runtime, where some of the thread-local accesses had to be in non-#[inline] functions to avoid them breaking cross-crate?

[alexcrichton]

@eddybyes, but probably not relevant today.

The MSVC support for #[thread_local] was only turned on very recently, and it segfaulted on all other Windows platforms, so it may be buggy and "accidentally" working, I'm not sure.

[eddyb]

@alexcrichton Do you think not having #[inline] on __getit on windows is reasonable?

[alexcrichton]

Personally, not really, but you seem eager to land this so I won't stop you if you'd like to do that. If you do, though, please leave a comment with as much information that you know.

[carols10cents]

friendly ping @eddyb to keep this on your radar!

[alexcrichton]

@bors: r-

This got back in the queue...