Add and use cfg(target_has_threads) to enforce no_thread impl usage by Mark-Simulacrum · Pull Request #158782 · rust-lang/rust

Mark-Simulacrum · 2026-07-04T16:00:07Z

The standard library has fallback code for targets without threads (e.g., using a Cell-based Mutex and similar). Today there's no enforcement in std that those targets truly don't have threads which makes that code potentially unsound. This will let us add a static assertion that the target spec agrees that the target is non-threaded. Getting the target spec wrong is already unsound (e.g., LLVM can make use of that) so it's a reasonable source of truth. This pulls in the atomics target feature into the target code and makes the field itself private to encourage going via the method.

For now the cfg is added as unstable but if we have a use case for user code to use this, happy to cut a tracking issue and make it a regular unstable feature.

Setting a compiler reviewer since the std changes are pretty trivial, and I think anyone can review those reasonably.

cc #156366 which prompted looking into this

r? compiler

rustbot · 2026-07-04T17:43:34Z

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

Urgau · 2026-07-04T18:57:03Z

            | (sym::target_pointer_width, Some(_))
            | (sym::target_vendor, None | Some(_))
            | (sym::target_has_atomic, Some(_))
+            | (sym::target_has_threads, Some(_))


We want to prevent --cfg target_has_threads so we need to lint on the none value.

Suggested change

| (sym::target_has_threads, Some(_))

| (sym::target_has_threads, None | Some(_))

Can you also add a test for it in tests/ui/cfg/disallowed-cli-cfgs.rs.

View changes since the review

Hm, interesting. I'll fix this but is it intentional that we allow users to pass e.g. --cfg 'windows="foo"'? That seems a bit confusing / probably unintentional, but from a quick test seems allowed?

IOW, why aren't all the options here restrictive? I guess it's a breaking change; do we normally FCP / search github / something for changes like this that stop allowing a cfg?

is it intentional that we allow users to pass e.g. --cfg 'windows="foo"'?

Yes, it's intentional, when we introduced the lint I was conservative and only linted against the cfgs we set, to not break people that might do --cfg 'windows="foo"', however il-advised that might be.

But this conservative logic doesn't apply to newly added cfgs, as it's very unlikely that someone is doing some shenanigans on not yet added builtin cfgs.

We could try and lint not matter the value.

I guess it's a breaking change

It's a lint change, and lint changes are not considered breaking changes.

We also document that the explicit_builtin_cfgs_in_flags lint against the builtin cfgs (that includes new ones), and have added other cfgs in that list without doing an FCP.

Urgau · 2026-07-04T18:57:15Z

r? Urgau

hanna-kruppe · 2026-07-04T19:23:02Z

Getting the target spec wrong is already unsound (e.g., LLVM can make use of that) so it's a reasonable source of truth.

Unfortunately it seems the target spec field isn't the full truth of what we tell LLVM:

rust/compiler/rustc_codegen_llvm/src/back/write.rs

Lines 214 to 218 in c397dae

    
           // On the wasm target once the `atomics` feature is enabled that means that 
        
           // we're no longer single-threaded, or otherwise we don't want LLVM to 
        
           // lower atomic operations to single-threaded operations. 
        
           if singlethread && sess.target.is_like_wasm && sess.target_features.contains(&sym::atomics) { 
        
               singlethread = false;

rustbot · 2026-07-04T21:47:30Z

These commits modify compiler targets.
(See the Target Tier Policy.)

curiousdannii · 2026-07-04T22:57:01Z

So with this, how would you enable threads in wasm32-emscripten?

Mark-Simulacrum · 2026-07-04T23:31:34Z

So with this, how would you enable threads in wasm32-emscripten?

This shouldn't change anything about behavior, if the target supports threads then it will work. See the previous comment (and fix to the PR since it) around wasm being special in having a target modifier changing the thread support.

@bors try jobs=dist-various-*

Add and use cfg(target_has_threads) to enforce no_thread impl usage try-job: dist-various-*

curiousdannii · 2026-07-04T23:49:56Z

This shouldn't change anything about behavior, if the target supports threads then it will work.

wasm32-emscripten's support of threads depends on which CFLAGS (or RUSTFLAGS, I forget which) you use.

Mark-Simulacrum · 2026-07-04T23:53:30Z

Right, that should be handled by the edit to consider whether the atomics target feature is set or not. This PR really isn't changing any behavior, it's just exposing what was already true, so it shouldn't have any meaningful effect. It may make it easier to see that code is broken (hence the try job as a quick check if there's targets with bad std impls).

curiousdannii · 2026-07-05T00:08:55Z

Yes, but wasm32-emscripten always says it has atomics, as you pointed out previously.

#156366 (comment)

This PR makes a lot of sense, I'm just not sure it will really improve things for our Emscripten target.

Should there really be a second Emscripten target for threads?

Mark-Simulacrum · 2026-07-05T00:27:41Z

Yes, but wasm32-emscripten always says it has atomics, as you pointed out previously.

It "has" atomics (i.e., the atomic types are defined), but unless -Ctarget-feature=+atomics is passed, they aren't real atomics. See https://rust.godbolt.org/z/3q9fsPx87 for example (edit to remove the command line argument to see that both functions compile the same without it). Note that we don't currently appear to enforce that said target feature is consistent across std and downstream libraries, which means that setting it is unsound (e.g., std will use non-atomic instructions and no-thread Mutex etc. to manipulate state that downstream code which enables the feature is expecting to be atomic). We'll need to make -Ctarget-feature=+atomics a target modifier but I think it makes sense to do that in a separate PR.

Regardless of that, this PR is an improvement for all targets because it means that we would know at compile-time of std if we get the cfg_select wrong and map a target to use the no-thread Mutex/etc. implementations despite the target actually having threads.

rust-bors · 2026-07-05T01:03:33Z

☀️ Try build successful (CI)
Build commit: e7f3db1 (e7f3db110a5277f652f7dc4ec3d959043493b0f7)
Base parent: c397dae (c397dae808f70caebab1fc4e11b3edf7e59f58c7)

Urgau

Make sense to me. Implementation looks good too.

View changes since this review

Urgau · 2026-07-05T12:28:43Z

@bors r+

rust-bors · 2026-07-05T12:28:45Z

📌 Commit ee37726 has been approved by Urgau

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 2. This pull request will be tested once the tree is reopened.

… r=Urgau Add and use cfg(target_has_threads) to enforce no_thread impl usage The standard library has fallback code for targets without threads (e.g., using a Cell-based Mutex and similar). Today there's no enforcement in std that those targets truly don't have threads which makes that code potentially unsound. This will let us add a static assertion that the target spec agrees that the target is non-threaded. Getting the target spec wrong is already unsound (e.g., LLVM can make use of that) so it's a reasonable source of truth. This pulls in the atomics target feature into the target code and makes the field itself private to encourage going via the method. For now the cfg is added as unstable but if we have a use case for user code to use this, happy to cut a tracking issue and make it a regular unstable feature. Setting a compiler reviewer since the std changes are pretty trivial, and I think anyone can review those reasonably. cc rust-lang#156366 which prompted looking into this r? compiler

JonathanBrouwer · 2026-07-05T19:25:32Z

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #158815 (comment)

rust-bors · 2026-07-05T19:25:37Z

This pull request was unapproved.

This PR was contained in a rollup (#158815), which was unapproved.

View changes since this unapproval

The standard library has fallback code for targets without threads (e.g., using a Cell-based Mutex and similar). Today there's no enforcement in std that those targets truly don't have threads which makes that code potentially unsound. This will let us add a static assertion that the target spec agrees that the target is non-threaded.

This avoids compiler/rustc_target/src/spec/mod.rs hitting tidy's file length check by moving out a chunk of code into a separate file. It's probably not the last such move needed (this only offsets ~100 lines), but it's a reasonable chunk of code to separate.

rustbot · 2026-07-05T19:47:16Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Mark-Simulacrum · 2026-07-05T19:49:39Z

No need for try builds, the failing "test" was a tidy file length check that didn't fail PR CI since that file grew on main after this opened. I split out some content from the relevant file (TargetTuple) in a second commit here which should bring us back under the limit (from ~3001 non-comment+non-blank lines to ~2889).

Mark-Simulacrum · 2026-07-05T21:11:31Z

@bors r=Urgau

(The code movement commit doesn't seem like it needs review, we can shuffle code again if there's any issues).

rust-bors · 2026-07-05T21:11:34Z

📌 Commit fe2db9c has been approved by Urgau

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 2. This pull request will be tested once the tree is reopened.

… r=Urgau Add and use cfg(target_has_threads) to enforce no_thread impl usage The standard library has fallback code for targets without threads (e.g., using a Cell-based Mutex and similar). Today there's no enforcement in std that those targets truly don't have threads which makes that code potentially unsound. This will let us add a static assertion that the target spec agrees that the target is non-threaded. Getting the target spec wrong is already unsound (e.g., LLVM can make use of that) so it's a reasonable source of truth. This pulls in the atomics target feature into the target code and makes the field itself private to encourage going via the method. For now the cfg is added as unstable but if we have a use case for user code to use this, happy to cut a tracking issue and make it a regular unstable feature. Setting a compiler reviewer since the std changes are pretty trivial, and I think anyone can review those reasonably. cc rust-lang#156366 which prompted looking into this r? compiler

Rollup of 20 pull requests Successful merges: - #158377 (add `-Zforce-intrinsic-fallback` flag) - #158642 (Clarify some interning details) - #158743 (Look for cdb location in the registry first) - #158775 (bootstrap: only encode RUSTFLAGS when a flag contains a space) - #158782 (Add and use cfg(target_has_threads) to enforce no_thread impl usage) - #158785 (hook intrinsic-test into aarch64-gnu) - #157734 (Stabilize `local_key_cell_update`) - #158183 (std: allocate less memory in `current_exe` for OpenBSD) - #158671 (Move tests batch 17) - #158730 (Update `FIXME(static_mut_refs)` comments) - #158752 (Reorganize `tests/ui/issues` [18/N]) - #158755 (Use `ThinVec` more in the AST) - #158757 (Fix incorrect tracking issue for `read_le`/`read_be`) - #158765 (Fix ICE on non-ident path in `doc(auto_cfg values)`) - #158771 (library: expand HashSet::extract_if coverage) - #158772 (rustc-dev-guide subtree update) - #158776 (fix: emit diagnostic for AVR target without target-cpu) - #158786 (Add regression test for builtin attr macro values) - #158807 (Add regression test for CString::clone_into unwind safety) - #158825 (Fix typo)

Rollup of 24 pull requests Successful merges: - #158377 (add `-Zforce-intrinsic-fallback` flag) - #158642 (Clarify some interning details) - #158694 (Positive test for closures needing expectations) - #158743 (Look for cdb location in the registry first) - #158775 (bootstrap: only encode RUSTFLAGS when a flag contains a space) - #158782 (Add and use cfg(target_has_threads) to enforce no_thread impl usage) - #158785 (hook intrinsic-test into aarch64-gnu) - #158819 (Put `InhabitedPredicate::NotInModule` earlier in disjunction since it can be a lot faster) - #157734 (Stabilize `local_key_cell_update`) - #158183 (std: allocate less memory in `current_exe` for OpenBSD) - #158310 (Remove unexpected usage of Unambig in non-infer variants) - #158671 (Move tests batch 17) - #158730 (Update `FIXME(static_mut_refs)` comments) - #158752 (Reorganize `tests/ui/issues` [18/N]) - #158755 (Use `ThinVec` more in the AST) - #158757 (Fix incorrect tracking issue for `read_le`/`read_be`) - #158765 (Fix ICE on non-ident path in `doc(auto_cfg values)`) - #158771 (library: expand HashSet::extract_if coverage) - #158772 (rustc-dev-guide subtree update) - #158776 (fix: emit diagnostic for AVR target without target-cpu) - #158786 (Add regression test for builtin attr macro values) - #158810 (Add supplementary information for get_unchecked(mut)) - #158825 (Fix typo) - #158838 (tidy: Use `empty_alternate = true` for triagebot mention glob check)

Rollup merge of #158782 - Mark-Simulacrum:expose-no-threads, r=Urgau Add and use cfg(target_has_threads) to enforce no_thread impl usage The standard library has fallback code for targets without threads (e.g., using a Cell-based Mutex and similar). Today there's no enforcement in std that those targets truly don't have threads which makes that code potentially unsound. This will let us add a static assertion that the target spec agrees that the target is non-threaded. Getting the target spec wrong is already unsound (e.g., LLVM can make use of that) so it's a reasonable source of truth. This pulls in the atomics target feature into the target code and makes the field itself private to encourage going via the method. For now the cfg is added as unstable but if we have a use case for user code to use this, happy to cut a tracking issue and make it a regular unstable feature. Setting a compiler reviewer since the std changes are pretty trivial, and I think anyone can review those reasonably. cc #156366 which prompted looking into this r? compiler

rustbot assigned Kivooeo Jul 4, 2026

Mark-Simulacrum mentioned this pull request Jul 4, 2026

Special-case emscripten without atomics to take no-threads path #156366

Open

Mark-Simulacrum marked this pull request as ready for review July 4, 2026 17:43

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 4, 2026

Mark-Simulacrum removed the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jul 4, 2026

Urgau reviewed Jul 4, 2026

View reviewed changes

rustbot assigned Urgau and unassigned Kivooeo Jul 4, 2026

Mark-Simulacrum force-pushed the expose-no-threads branch from cb02160 to ee37726 Compare July 4, 2026 21:47

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jul 4, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Jul 4, 2026

Auto merge of #158782 - Mark-Simulacrum:expose-no-threads, r=<try>

e7f3db1

Add and use cfg(target_has_threads) to enforce no_thread impl usage try-job: dist-various-*

Urgau approved these changes Jul 5, 2026

View reviewed changes

rust-bors Bot 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 Jul 5, 2026

JonathanBrouwer mentioned this pull request Jul 5, 2026

Rollup of 12 pull requests #158815

Closed

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 5, 2026

Mark-Simulacrum added 2 commits July 5, 2026 15:29

Mark-Simulacrum force-pushed the expose-no-threads branch from ee37726 to fe2db9c Compare July 5, 2026 19:47

rust-bors Bot 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 5, 2026

jhpratt mentioned this pull request Jul 6, 2026

Rollup of 20 pull requests #158837

Closed

jhpratt mentioned this pull request Jul 6, 2026

Rollup of 24 pull requests #158847

Merged

rust-bors Bot merged commit beeaa7a into rust-lang:main Jul 6, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Jul 6, 2026

	\| (sym::target_has_threads, Some(_))
	\| (sym::target_has_threads, None \| Some(_))

Uh oh!

Uh oh!

Conversation

Mark-Simulacrum commented Jul 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 4, 2026

Uh oh!

Urgau Jul 4, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

Urgau Jul 4, 2026

Choose a reason for hiding this comment

Uh oh!

Urgau commented Jul 4, 2026

Uh oh!

hanna-kruppe commented Jul 4, 2026

Uh oh!

rustbot commented Jul 4, 2026

Uh oh!

curiousdannii commented Jul 4, 2026

Uh oh!

Mark-Simulacrum commented Jul 4, 2026

Uh oh!

This comment has been minimized.

curiousdannii commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mark-Simulacrum commented Jul 4, 2026

Uh oh!

curiousdannii commented Jul 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mark-Simulacrum commented Jul 5, 2026

Uh oh!

rust-bors Bot commented Jul 5, 2026

Uh oh!

Urgau left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Urgau commented Jul 5, 2026

Uh oh!

rust-bors Bot commented Jul 5, 2026

Uh oh!

JonathanBrouwer commented Jul 5, 2026

Uh oh!

rust-bors Bot commented Jul 5, 2026

Uh oh!

rustbot commented Jul 5, 2026

Uh oh!

Mark-Simulacrum commented Jul 5, 2026

Uh oh!

Mark-Simulacrum commented Jul 5, 2026

Uh oh!

rust-bors Bot commented Jul 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Mark-Simulacrum commented Jul 4, 2026 •

edited by rustbot

Loading

Urgau Jul 4, 2026 •

edited by rustbot

Loading

curiousdannii commented Jul 4, 2026 •

edited

Loading

curiousdannii commented Jul 5, 2026 •

edited

Loading

Urgau left a comment •

edited by rustbot

Loading