Check that nested statics in thread locals are duplicated per thread. by oli-obk · Pull Request #123362 · rust-lang/rust

oli-obk · 2024-04-02T12:10:24Z

follow-up to #123310

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 · 2024-04-02T12:10:32Z

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

RalfJung · 2024-04-02T12:28:28Z

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 · 2024-04-02T12:35:37Z

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 · 2024-04-02T13:00:56Z

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

compiler-errors · 2024-04-02T15:31:45Z

tests/ui/statics/nested_thread_local.rs

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


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

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.

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

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

🤦 of course!

compiler-errors · 2024-04-02T15:32:31Z

tests/ui/statics/nested_thread_local.stderr

+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 = {


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.

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.

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

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

compiler-errors

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

RalfJung · 2024-04-02T16:39:13Z

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 · 2024-04-02T16:56:19Z

@bors r+

bors · 2024-04-02T16:56:22Z

📌 Commit 64b75f7 has been approved by estebank

It is now in the queue for this repository.

…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.

…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 · 2024-04-02T22:05:19Z

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:

Tracking issue for thread_local stabilization #29594 (comment)

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

oli-obk · 2024-04-02T22:09:21Z

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

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.

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

6c5c48e

rustbot assigned estebank Apr 2, 2024

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

Forbid implicit nested statics in thread local statics

64b75f7

compiler-errors reviewed Apr 2, 2024

View reviewed changes

compiler-errors approved these changes Apr 2, 2024

View reviewed changes

estebank approved these changes Apr 2, 2024

View reviewed changes

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

This was referenced Apr 2, 2024

Rollup of 8 pull requests #123381

Closed

Rollup of 8 pull requests #123385

Merged

bors merged commit 5b71768 into rust-lang:master Apr 2, 2024

rustbot added this to the 1.79.0 milestone Apr 2, 2024

Uh oh!

Conversation

oli-obk commented Apr 2, 2024

Uh oh!

rustbot commented Apr 2, 2024

Uh oh!

RalfJung commented Apr 2, 2024

Uh oh!

oli-obk commented Apr 2, 2024

Uh oh!

rustbot commented Apr 2, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compiler-errors Apr 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compiler-errors left a comment

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Apr 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

estebank commented Apr 2, 2024

Uh oh!

bors commented Apr 2, 2024

Uh oh!

workingjubilee commented Apr 2, 2024

Uh oh!

oli-obk commented Apr 2, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

compiler-errors Apr 2, 2024 •

edited

Loading

RalfJung commented Apr 2, 2024 •

edited

Loading