The miri engine may create pointers to thread locals

[oli-obk]

I haven't checked whether that is actually true, but we should have an unleash-the-miri-inside-of-you test for the following code snippet. In contrast to normal compilation I expect this to pass compilation and then segfault LLVM or similar, but we may catch it. No matter the result, we should have a test for it.

#![feature(thread_local)]

use std::thread;

#[thread_local]
static mut A: u8 = 0;

static B: &u8 = unsafe { &A };

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
warning: unused import: `std::thread`
 --> src/lib.rs:3:5
  |
3 | use std::thread;
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error[E0625]: thread-local statics cannot be accessed at compile-time
 --> src/lib.rs:8:27
  |
8 | static B: &u8 = unsafe { &A };
  |                           ^

error: aborting due to previous error

error: could not compile `playground`.

To learn more, run the command again with --verbose.

[eddyb]

As I suggested elsewhere, I believe #[thread_local] statics should have their own separate access mechanism, probably their own Rvalue (or we could start extending what Rvalue::{Ref,RawPtr} can borrow).

That's because getting the address of a #[thread_local] static is a fundamentally runtime operation, and LLVM reusing the same syntax as for regular statics, is in the wrong here.

[oli-obk]

The "elsewhere" now having a canonical issue: #70685

[oli-obk]

Ah so this won't work even with unleash mode, because of

rust/src/librustc_mir/transform/check_consts/ops.rs

Line 372 in 57e1da5

const IS_SUPPORTED_IN_MIRI: bool = false;

I guess we can address this together with #70685, our existing tests should be enough then