Don't inherit codegen attrs from parent static

[compiler-errors]

Putting this up partly for discussion and partly for review. Specifically, in #121644, @oli-obk designed a system that creates new static items for representing nested allocations in statics. However, in that PR, oli made it so that these statics inherited the codegen attrs from the parent.

This causes problems such as colliding symbols with #[export_name] and ICEs with #[no_mangle] since these synthetic statics have no tcx.item_name(..).

So the question is, is there any case where we do want to inherit codegen attrs from the parent? The only one that seems a bit suspicious is the thread-local attribute. And there may be some interesting interactions with the coverage attributes as well...

Fixes (after backport) #123274. Fixes #123243. cc #121644.

r? @oli-obk cc @nnethercote @RalfJung (reviewers on that pr)

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[workingjubilee]

Hm. I would expect that if nested statics inside #[thread_local] was not, by default, thread_local all the way down, barring certain optimizations, something would get very fucky when someone inevitably has a bad idea involving nested RefCell inside #[thread_local].

...I may be wrong about how the nesting would work out, but I swear that I have indeed seen code like RefCell<Container<RefCell<T>>>.

[compiler-errors]

Well it doesn't seem to matter with this PR:

#![feature(thread_local)]

use std::cell::RefCell;

#[thread_local]
static FOO: RefCell<RefCell<i32>> = RefCell::new(RefCell::new(0));

fn main() {
    *FOO.borrow_mut().borrow_mut() = 1;

    let _ = std::thread::spawn(|| {
        let y = *FOO.borrow().borrow();
        println!("{y}");
    }).join();

    let y = *FOO.borrow().borrow();
    println!("{y}");
}

This continues to print 0 1. But it may just be that I'm not creative enough to come up with an example where this would matter.

I think even "thread locals" are a bit misleading here -- the attr seems to only affect MIR building and the creation of thread-local shims. This doesn't seem really relevant to static items that are anonymous.

[workingjubilee]

Huh, weird/neat!

[oli-obk]

Nested statics only get created when there are indirections. I need to check how thread local statics work in detail, maybe we can just hard error when we try to have mutable nested statics in thread local statics.

[oli-obk]

This ICEs in const eval during validation

#![feature(const_refs_to_cell)]
#![feature(thread_local)]

use std::cell::RefCell;

#[thread_local]
static mut FOO: &mut u32 = &mut 42;

fn main() {
    unsafe {
    *FOO = 1;

    let _ = std::thread::spawn(|| {
        let y = *;
        println!("{y}");
    }).join();

    let y = *FOO;
    println!("{y}");
}
}

[oli-obk]

I wonder what to do about link-section. If there are nested mutable statics, I'd potentially expect them to live in the same link section.

More and more it feels like we will want to error when there are some flags on the parent, but that's orthogonal to this PR. After this PR we get back the original behaviour, no matter how fishy

@bors r+

[bors]

📌 Commit 4ff8a9b has been approved by oli-obk

It is now in the queue for this repository.

[RalfJung]

Oh yeah thread-locals are fun. Even without mutability they will cause problems I think. Could you open an issue for that?

[bors]

⌛ Testing commit 4ff8a9b with merge 3d5528c...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 3d5528c to master...

[rust-timer]

Finished benchmarking commit (3d5528c): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.3%	[1.0%, 1.5%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.3%	[1.0%, 1.5%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.4%	[1.4%, 1.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 667.778s -> 669.305s (0.23%)
Artifact size: 315.75 MiB -> 315.75 MiB (-0.00%)

[apiraino]

Beta backport accepted as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle.

@rustbot label +beta-accepted