Destabilise `target-spec-json` by davidtwco · Pull Request #150151 · rust-lang/rust

davidtwco · 2025-12-19T11:59:45Z

Per #71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std).

Current build-std RFCs (rust-lang/rfcs#3873, rust-lang/rfcs#3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc.

De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.

rustbot · 2025-12-19T11:59:49Z

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

rustbot · 2025-12-19T11:59:52Z

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
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

Kivooeo · 2025-12-19T13:35:34Z

r? me

@bors r+ rollup

bors · 2025-12-19T13:35:37Z

📌 Commit 6c4c438 has been approved by Kivooeo

It is now in the queue for this repository.

…json, r=Kivooeo Destabilise `target-spec-json` Per rust-lang/compiler-team#944: > Per rust-lang#71009, the ability to load target spec JSONs was stabilised accidentally. Within the team, we've always considered the format to be unstable and have changed it freely. This has been feasible as custom targets can only be used with core, like any other target, and so custom targets de-facto require nightly to be used (i.e. to build core manually or use Cargo's -Zbuild-std). > > Current build-std RFCs (rust-lang/rfcs#3873, rust-lang/rfcs#3874) propose a mechanism for building core on stable (at the request of Rust for Linux), which combined with a stable target-spec-json format, permit the current format to be used much more widely on stable toolchains. This would prevent us from improving the format - making it less tied to LLVM, switching to TOML, enabling keys in the spec to be stabilised individually, etc. > > De-stabilising the format gives us the opportunity to improve the format before it is too challenging to do so. Internal company toolchains and projects like Rust for Linux already use target-spec-json, but must use nightly at some point while doing so, so while it could be inconvenient for those users to destabilise this, it is hoped that an minimal alternative that we could choose to stabilise can be proposed relatively quickly.

Rollup of 7 pull requests Successful merges: - #149633 (Enable `outline-atomics` by default on AArch64 FreeBSD) - #149788 (Move shared offload globals and define per-kernel globals once) - #149989 (Improve filenames encoding and misc) - #150012 (rustc_target: Add `efiapi` ABI support for LoongArch) - #150116 (layout: Store inverse memory index in `FieldsShape::Arbitrary`) - #150151 (Destabilise `target-spec-json`) - #150159 (Split eii macro expansion code) r? `@ghost` `@rustbot` modify labels: rollup

matthiaskrgr · 2025-12-19T22:38:35Z

@bors r-
#150168 (comment)

Kivooeo · 2025-12-19T22:53:25Z

I don't see why exactly it fails, but the problem in src/tools/cargo/tests/testsuite/rustc.rs in rustc_with_print_cfg_config_toml_env test

rustc is destabilising custom targets (rust-lang/rust#150151) and requiring that `-Zunstable-options` is passed when custom targets are used. This is the minimum change required so that the rustc patch can be merged.

davidtwco · 2026-01-05T12:11:29Z

Submitted rust-lang/cargo#16467 to adjust the Cargo test, then after the Cargo submodule update this will be able to be merged.

rustc is destabilising custom targets (rust-lang/rust#150151) and requiring that `-Zunstable-options` is passed when custom targets are used. This is the minimum change required so that the rustc patch can be merged.

JSON target specifications were destabilized in rust-lang/rust#150151 and now require this additional flag

…c` feature (#1455) Experimental: Update translations using AI. JSON target specifications were destabilized in rust-lang/rust#150151 Code update in #1456

…json-again, r=chenyukang target: fix destabilising target-spec-json cc rust-lang#151528 rust-lang#150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that. Closes rust-lang#71009

Rollup merge of #151534 - davidtwco:destabilise-target-spec-json-again, r=chenyukang target: fix destabilising target-spec-json cc #151528 #150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that. Closes #71009

RalfJung · 2026-02-05T17:50:01Z

So now we need to pass -Zunstable-options to rustc and -Zjson-target-spec to cargo?

It is taking me many, many tries to get this to work in Miri's CI. It's often not even clear which of the two tools is complaining about the missing flags...

ChrisDenton · 2026-02-06T08:12:15Z

So now we need to pass -Zunstable-options to rustc and -Zjson-target-spec to cargo?

It is taking me many, many tries to get this to work in Miri's CI. It's often not even clear which of the two tools is complaining about the missing flags...

Maybe that could be addressed by cargo?

…custom-targets, r=scottmcm compiletest: `-Zunstable-options` for json targets bootstrap runs compiletest with synthetic custom targets when blessing `mir-opt` tests, but that no longer works after rust-lang#150151/rust-lang#151534 because `-Zunstable-options` is required Contexts on [Zulips](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/custom.20targets.20are.20unstable.20and.20require.20.60-Zunstable-options.60).

Rollup merge of #152236 - davidtwco:compiletest-destabilise-custom-targets, r=scottmcm compiletest: `-Zunstable-options` for json targets bootstrap runs compiletest with synthetic custom targets when blessing `mir-opt` tests, but that no longer works after #150151/#151534 because `-Zunstable-options` is required Contexts on [Zulips](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/custom.20targets.20are.20unstable.20and.20require.20.60-Zunstable-options.60).

With the json target specification format destabilized in rust-lang#150151, `-Zjson-target-spec` is needed for custom targets. This should resolve the CI failures seen in rust-lang/compiler-builtins#1070

JSON target specs were destabilized in rust-lang#150151 and rust-lang#151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets). There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`. Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](https://github.com/rust-lang/cargo/blob/592058c7ce08a2ba2628b01e7dc4ce1e72b6bdff/src/cargo/core/compiler/compile_kind.rs#L144-L154). I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc. This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI). After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from rust-lang/cargo#16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in f0bdd35, which could be adapted if desired. It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target. Fixes rust-lang#151729

…rgets, r=scottmcm compiletest: `-Zunstable-options` for json targets bootstrap runs compiletest with synthetic custom targets when blessing `mir-opt` tests, but that no longer works after rust-lang/rust#150151/rust-lang/rust#151534 because `-Zunstable-options` is required Contexts on [Zulips](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/custom.20targets.20are.20unstable.20and.20require.20.60-Zunstable-options.60).

JSON target specs were destabilized in rust-lang#150151 and rust-lang#151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets). There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`. Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](https://github.com/rust-lang/cargo/blob/592058c7ce08a2ba2628b01e7dc4ce1e72b6bdff/src/cargo/core/compiler/compile_kind.rs#L144-L154). I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc. This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI). After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from rust-lang/cargo#16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in f0bdd35, which could be adapted if desired. It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target. Fixes rust-lang#151729

This reverts rust-lang#150151 in order to deal with rust-lang#151729 where the destabilization caused a problem with building rustc itself with JSON target specs. There's a fix at rust-lang#152677, but we would prefer to not backport that, and instead give ourselves more time to work out the kinks. Also, the destabilization was incomplete, and the rest of the changes are in 1.95 (rust-lang#151534 and rust-lang/cargo#16557), so it would be nice to keep all the changes together in one release. This reverts commit a89683d, reversing changes made to 2f1bd3f.

…,jieyouxu Support JSON target specs in bootstrap JSON target specs were destabilized in #150151 and #151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets). There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`. Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](https://github.com/rust-lang/cargo/blob/592058c7ce08a2ba2628b01e7dc4ce1e72b6bdff/src/cargo/core/compiler/compile_kind.rs#L144-L154). I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc. This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI). After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from rust-lang/cargo#16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in ehuss@f0bdd35, which could be adapted if desired. It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target. Fixes #151729

[beta] Revert destabilise target-spec-json This reverts #150151 in order to deal with #151729 where the destabilization caused a problem with building rustc itself with JSON target specs. There's a fix at #152677, but we would prefer to not backport that, and instead give ourselves more time to work out the kinks. Also, the destabilization was incomplete, and the rest of the changes are in 1.95 (#151534 and rust-lang/cargo#16557), so it would be nice to keep all the changes together in one release. This reverts commit a89683d, reversing changes made to 2f1bd3f.

…,jieyouxu Support JSON target specs in bootstrap JSON target specs were destabilized in rust-lang/rust#150151 and rust-lang/rust#151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets). There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`. Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](https://github.com/rust-lang/cargo/blob/592058c7ce08a2ba2628b01e7dc4ce1e72b6bdff/src/cargo/core/compiler/compile_kind.rs#L144-L154). I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc. This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI). After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from rust-lang/cargo#16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in ehuss/rust@f0bdd35, which could be adapted if desired. It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target. Fixes rust-lang/rust#151729

[beta] Revert destabilise target-spec-json This reverts #150151 in order to deal with #151729 where the destabilization caused a problem with building rustc itself with JSON target specs. There's a fix at #152677, but we would prefer to not backport that, and instead give ourselves more time to work out the kinks. Also, the destabilization was incomplete, and the rest of the changes are in 1.95 (#151534 and rust-lang/cargo#16557), so it would be nice to keep all the changes together in one release. This reverts commit a89683d, reversing changes made to 2f1bd3f.

destabilise target-spec-json

6c4c438

rustbot added A-run-make Area: port run-make Makefiles to rmake.rs 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 Dec 19, 2025

rustbot assigned JonathanBrouwer Dec 19, 2025

rustbot assigned Kivooeo Dec 19, 2025

rustbot unassigned JonathanBrouwer Dec 19, 2025

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 Dec 19, 2025

matthiaskrgr mentioned this pull request Dec 19, 2025

Rollup of 6 pull requests #150167

Closed

matthiaskrgr mentioned this pull request Dec 19, 2025

Rollup of 7 pull requests #150168

Closed

bors 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 Dec 19, 2025

Mark-Simulacrum added the relnotes Marks issues that should be documented in the release notes of the next release. label Dec 20, 2025

rustbot mentioned this pull request Dec 20, 2025

Tracking issue for release notes of #150151: Destabilise target-spec-json #150179

Closed

davidtwco mentioned this pull request Jan 5, 2026

test: add -Zunstable-options with custom targets rust-lang/cargo#16467

Merged

davidtwco added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 5, 2026

phil-opp added a commit to phil-opp/blog_os that referenced this pull request Feb 4, 2026

Enable unstable json-target-spec feature (#1456)

49f67e4

JSON target specifications were destabilized in rust-lang/rust#150151 and now require this additional flag

davidtwco mentioned this pull request Feb 6, 2026

compiletest: -Zunstable-options for json targets #152236

Merged

ehuss mentioned this pull request Feb 15, 2026

Support JSON target specs in bootstrap #152677

Merged

jieyouxu mentioned this pull request Feb 16, 2026

Double-check rustc flag handling in bootstrap #152709

Open

ehuss mentioned this pull request Feb 16, 2026

[beta] Revert destabilise target-spec-json #152721

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comments

Destabilise `target-spec-json`#150151

Destabilise `target-spec-json`#150151
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
davidtwco:destabilise-target-spec-json

davidtwco commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025

Uh oh!

bors commented Dec 19, 2025

Uh oh!

matthiaskrgr commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025 •

edited

Loading

Uh oh!

davidtwco commented Jan 5, 2026

Uh oh!

RalfJung commented Feb 5, 2026

Uh oh!

ChrisDenton commented Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Uh oh!

Comments

Conversation

davidtwco commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025

Uh oh!

bors commented Dec 19, 2025

Uh oh!

matthiaskrgr commented Dec 19, 2025

Uh oh!

Kivooeo commented Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidtwco commented Jan 5, 2026

Uh oh!

RalfJung commented Feb 5, 2026

Uh oh!

ChrisDenton commented Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

Kivooeo commented Dec 19, 2025 •

edited

Loading