#[no_mangle] in thread_local! requires unsafe wrapping in edition 2021

[elftausend]

I tried this code to compile in Edition 2021:

#[no_mangle] // fine
static TEST_OUTSIDE: usize = 0;

thread_local! {
    #[no_mangle] // unsafe attribute used without unsafe wrap error
    static TEST: usize = 0;
}

However, compilation fails because the attribute must be wrapped in unsafe(...).
This breaks existing libraries like litequad, even though it wasn't upgraded to edition 2024.

Meta

[package]
name = "no_mangle_test"
version = "0.1.0"
edition = "2021"

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a63572490a930b126b003b57c58c9df0

error: unsafe attribute used without unsafe
 --> src/main.rs:6:7
  |
6 |     #[no_mangle]
  |       ^^^^^^^^^ usage of unsafe attribute
  |
help: wrap the attribute in `unsafe(...)`
  |
6 |     #[unsafe(no_mangle)]
  |       +++++++         +

error: could not compile `no_mangle_test` (bin "no_mangle_test") due to 1 previous error

[workingjubilee]

this seems to be a similar class of bug as to what we fixed via #138717 because the spans get their edition based on the crate the macro is defined in, and for a more recent rustc, std is Edition 2024

[bjorn3]

I don't think #[no_mangle] inside thread_local! {} is supposed to work. What would it actually apply to? The #[thread_local] static? (there may not be any), the static containing the pthread_key_t (again there may not be any), the std::thread::LocalKey (likely to surprise people who want to interoperate with C and it may not even be stored in a static in the first place) or something else?

[workingjubilee]

...that is an interesting question, yeah.

[apiraino]

@elftausend I'm slightly confused about which edition that snippet used to compile for you (IIUC your report). Does it compile with --edition=2018 or --edition=2021? Can you share how do you exactly compile that snippet? Thanks

[hanna-kruppe]

It not compiling with older edition but new Rust release is the bug. The playground only has the newest stable Rust, but you can compare 1.87 vs 1.86 on godbolt.

[apiraino]

thanks @hanna-kruppe. Yes, as probably expected this started in #138162 when the standard library moved to Edition 2024

[ehuss]

As for why this is happening, this is mostly an unfortunate result of needing to use $meta. The edition checking code here only looks at the entire span of the attribute. This means that the # token is the load-bearing token for determining the edition. The thread_local attribute is ignoring/dropping the # token from the input and substituting it with its own here.

My expectation would be that the name of the attribute should be the span that it checks for the edition.

I think that could be implemented by calling attr.get_normal_item().span() instead of attr.span() (or something like that).
cc @compiler-errors @folkertdev if that would make sense?

[folkertdev]

We're kind of close to the next release, but should we backport this to beta and unbreak the affected crates 6 weeks earlier?

[apiraino]

@folkertdev just for my understanding : by "this" you mean #142261 (the patch fixing this issue), right?

[folkertdev]

yes, exactly