r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

This may help ensure that the thread local doesn't end up in a separate module to the code that accesses it.

I assume module here means e.g., CGU or similar? If this is important to ensure, it seems like we ought to have at least a comment on the code, and ideally some kind of test -- otherwise it seems easy for this PR to get lost in a refactoring.

Module means "dll" or "exe" here. IIRC I was seeing issues when running stage 1 tests where sometimes TLS access was being inlined across normal boundaries. Though this didn't appear to affect stage 2 builds as far as I could tell. I guess this is ultimately a compiler bug because it shouldn't be doing that ever. The thread_local! macro works around the problem by making get() be #[inline(never)]. That might work here too.

Though having just rerun ui tests now I'm not seeing the failure. Maybe things have changed.

I think inline(never) makes me less worried about accidentally reverting it, at least -- it seems like the better change here. I agree that the situation you're describing shouldn't happen though...

Closing in favour of #100007