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

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

Merged
merged 2 commits into from
Apr 2, 2024

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented Apr 2, 2024

follow-up to #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.

@rustbot
Copy link
Collaborator

rustbot commented Apr 2, 2024

r? @estebank

rustbot has assigned @estebank.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 2, 2024
@RalfJung
Copy link
Member

RalfJung commented Apr 2, 2024

I'm just going to start hard erroring on nested mutable statics in thread locals.

Why only for nested mutable statics? I don't think mutability should make a difference here.

@oli-obk
Copy link
Contributor Author

oli-obk commented Apr 2, 2024

Why only for nested mutable statics? I don't think mutability should make a difference here.

funny you ask. The first thing I tried was to just outlaw any nested statics, and it seems to pass all tests

@rustbot
Copy link
Collaborator

rustbot commented Apr 2, 2024

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

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

#[thread_local]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this not also affect thread_local!() macro invokations? It should, since those just desugar to #[thread_local] internally?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but those always desugar to a Key<StaticsType>, which is always initialized with None internally, and then set to Some by computing a value at runtime at thread start.

Copy link
Member

@compiler-errors compiler-errors Apr 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm looking at the implementation of thread_local_inner in library/std/src/sys/thread_local/fast_local.rs, which initializes:

#[thread_local]
// We use `UnsafeCell` here instead of `static mut` to ensure any generated TLS shims
// have a nonnull attribute on their return value.
static VAL: $crate::cell::UnsafeCell<$t> = $crate::cell::UnsafeCell::new(INIT_EXPR);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notice INIT_EXPR, not $init_expr. It is first stored in a const and then assigned here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤦 of course!

error: #[thread_local] does not support implicit nested statics, please create explicit static items and refer to them instead
--> $DIR/nested_thread_local.rs:7:1
|
LL | static mut FOO: &u32 = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to extract a more exact span from the allocation? Specifically, I'd like a label on the &{ x } part that says "this is promoted" or something.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Miri extends the interpreter with more detailed tracking of where each allocation comes from, but so far the compile-time interpreter does not have that information. Maybe we should add a Span to the core allocation type rather than just doing this as a Miri extension.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just wondering about that when I saw this error. We can see how perf is affected, but it would be really nice for many diagnostics

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... but in a separate PR, please. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lmao yes

Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok i'm happy with this then, thx for the answers to my dumb questions lol

@RalfJung
Copy link
Member

RalfJung commented Apr 2, 2024

Are there tests to ensure that thread_local! with something like &Vec::new() (not a promoted) will keep working?

EDIT: Ah, yes, there's a test like that.

@estebank
Copy link
Contributor

estebank commented Apr 2, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Apr 2, 2024

📌 Commit 64b75f7 has been approved by estebank

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 2, 2024
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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 2, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#123198 (Add fn const BuildHasherDefault::new)
 - rust-lang#123226 (De-LLVM the unchecked shifts [MCP#693])
 - rust-lang#123302 (Make sure to insert `Sized` bound first into clauses list)
 - rust-lang#123348 (rustdoc: add a couple of regression tests)
 - rust-lang#123362 (Check that nested statics in thread locals are duplicated per thread.)
 - rust-lang#123368 (CFI: Support non-general coroutines)
 - rust-lang#123375 (rustdoc: synthetic auto trait impls: accept unresolved region vars for now)
 - rust-lang#123378 (Update sysinfo to 0.30.8)

Failed merges:

 - rust-lang#123349 (Fix capture analysis for by-move closure bodies)

r? `@ghost`
`@rustbot` modify labels: rollup
@workingjubilee
Copy link
Member

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.

That is not what everyone imagines to be the case:

I realize #[thread_local] has seen very little motion forward in the past 9 years but it's hardly uniquely guilty there.

@oli-obk
Copy link
Contributor Author

oli-obk commented Apr 2, 2024

Yea, I noticed when I tried to make thr feature gate internal 😅

Still, the hard error, while low quality, prevents any issues from cropping up. Working on improving it via giving Allocations a Span as discussed above

@bors bors merged commit 5b71768 into rust-lang:master Apr 2, 2024
11 checks passed
@rustbot rustbot added this to the 1.79.0 milestone Apr 2, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

7 participants