Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't inherit codegen attrs from parent static #123310

Merged
merged 1 commit into from
Apr 1, 2024

Conversation

compiler-errors
Copy link
Member

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
Copy link
Collaborator

rustbot commented Apr 1, 2024

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 1, 2024
@compiler-errors compiler-errors added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 1, 2024
@workingjubilee
Copy link
Member

workingjubilee commented Apr 1, 2024

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
Copy link
Member Author

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
Copy link
Member

Huh, weird/neat!

@oli-obk
Copy link
Contributor

oli-obk commented Apr 1, 2024

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
Copy link
Contributor

oli-obk commented Apr 1, 2024

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
Copy link
Contributor

oli-obk commented Apr 1, 2024

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
Copy link
Contributor

bors commented Apr 1, 2024

📌 Commit 4ff8a9b has been approved by oli-obk

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 1, 2024
@RalfJung
Copy link
Member

RalfJung commented Apr 1, 2024

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

@bors
Copy link
Contributor

bors commented Apr 1, 2024

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

@bors
Copy link
Contributor

bors commented Apr 1, 2024

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 1, 2024
@bors bors merged commit 3d5528c into rust-lang:master Apr 1, 2024
12 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Apr 1, 2024
@compiler-errors compiler-errors deleted the nested-static-codegen-attrs branch April 1, 2024 13:24
@rust-timer
Copy link
Collaborator

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%)

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 2, 2024
…s, r=estebank

Check that nested statics in thread locals are duplicated per thread.

follow-up to rust-lang#123310

cc `@compiler-errors` `@RalfJung`

fwiw: I have no idea how thread local statics make that work under LLVM, and miri fails on this example, which I would have expected to be the correct behaviour.

Since the `#[thread_local]` attribute is just an internal implementation detail, I'm just going to start hard erroring on nested mutable statics in thread locals.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Apr 2, 2024
…s, r=estebank

Check that nested statics in thread locals are duplicated per thread.

follow-up to rust-lang#123310

cc ``@compiler-errors`` ``@RalfJung``

fwiw: I have no idea how thread local statics make that work under LLVM, and miri fails on this example, which I would have expected to be the correct behaviour.

Since the `#[thread_local]` attribute is just an internal implementation detail, I'm just going to start hard erroring on nested mutable statics in thread locals.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Apr 2, 2024
Rollup merge of rust-lang#123362 - oli-obk:thread_local_nested_statics, r=estebank

Check that nested statics in thread locals are duplicated per thread.

follow-up to rust-lang#123310

cc ``@compiler-errors`` ``@RalfJung``

fwiw: I have no idea how thread local statics make that work under LLVM, and miri fails on this example, which I would have expected to be the correct behaviour.

Since the `#[thread_local]` attribute is just an internal implementation detail, I'm just going to start hard erroring on nested mutable statics in thread locals.
@apiraino
Copy link
Contributor

apiraino commented Apr 4, 2024

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

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Apr 4, 2024
@cuviper cuviper mentioned this pull request Apr 4, 2024
@cuviper cuviper modified the milestones: 1.79.0, 1.78.0 Apr 4, 2024
@cuviper cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 4, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 5, 2024
[beta] backports

- Fix f16 and f128 feature gates in editions other than 2015 rust-lang#123307 / rust-lang#123445
- Update to LLVM 18.1.2 rust-lang#122772
- unix fs: Make hurd using explicit new rather than From rust-lang#123057
- Don't inherit codegen attrs from parent static rust-lang#123310
- Make sure to insert Sized bound first into clauses list rust-lang#123302

r? cuviper
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 6, 2024
[beta] backports

- Fix f16 and f128 feature gates in editions other than 2015 rust-lang#123307 / rust-lang#123445
- Update to LLVM 18.1.2 rust-lang#122772
- unix fs: Make hurd using explicit new rather than From rust-lang#123057
- Don't inherit codegen attrs from parent static rust-lang#123310
- Make sure to insert Sized bound first into clauses list rust-lang#123302

r? cuviper
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE: item_name: no name for DefPath
9 participants