Destabilise `target-spec-json` #150151

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.

rustc is destabilising custom targets (rust-lang/rust#150151) by requiring that `-Zunstable-options` is passed when custom targets are used. This patch is the minimum change required so that the rustc patch can be merged without failing the Cargo tests run in rustc's CI.

davidtwco · 2026-01-12T13:03:54Z

I believe the Cargo submodule was updated in #150932 so this can be retried.

@bors r=Kivooeo rollup- (no rollup just in case there are additional issues)

rust-bors · 2026-01-12T13:03:59Z

📌 Commit 6c4c438 has been approved by Kivooeo

It is now in the queue for this repository.

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

@ghost

…uwer Rollup of 13 pull requests Successful merges: - #145343 (Dogfood `-Zno-embed-metadata` in the standard library) - #150151 (Destabilise `target-spec-json`) - #150723 (std: move `errno` and related functions into `sys::io`) - #150771 (Remove legacy homu `try` and `auto` branch mentions) - #150826 (Add `f16` inline ASM support for s390x) - #150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - #150943 (Port `#[must_not_suspend]` to attribute parser) - #150990 (std: sys: net: uefi: Make TcpStream Send) - #150995 (core: ptr: split_at_mut: fix typo in safety doc) - #150998 (Relax test expectation for @__llvm_profile_runtime_user) - #151002 (Remove a workaround for a bug (take 2)) - #151005 (Fix typo in `MaybeUninit` docs) - #151011 (Update books) r? @ghost

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

@ghost

Rollup of 12 pull requests Successful merges: - #145343 (Dogfood `-Zno-embed-metadata` in the standard library) - #150151 (Destabilise `target-spec-json`) - #150723 (std: move `errno` and related functions into `sys::io`) - #150826 (Add `f16` inline ASM support for s390x) - #150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - #150943 (Port `#[must_not_suspend]` to attribute parser) - #150990 (std: sys: net: uefi: Make TcpStream Send) - #150995 (core: ptr: split_at_mut: fix typo in safety doc) - #150998 (Relax test expectation for @__llvm_profile_runtime_user) - #151002 (Remove a workaround for a bug (take 2)) - #151005 (Fix typo in `MaybeUninit` docs) - #151011 (Update books) r? @ghost

@ghost

…uwer Rollup of 14 pull requests Successful merges: - #150151 (Destabilise `target-spec-json`) - #150826 (Add `f16` inline ASM support for s390x) - #150883 (Improve span for "unresolved intra doc link" on `deprecated` attribute) - #150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - #150943 (Port `#[must_not_suspend]` to attribute parser) - #150990 (std: sys: net: uefi: Make TcpStream Send) - #150995 (core: ptr: split_at_mut: fix typo in safety doc) - #150998 (Relax test expectation for @__llvm_profile_runtime_user) - #151002 (Remove a workaround for a bug (take 2)) - #151005 (Fix typo in `MaybeUninit` docs) - #151011 (Update books) - #151029 (rustc-dev-guide subtree update) - #151032 (fix: added missing backtick in triagebot.toml) - #151035 (Don't suggest replacing closure parameter with type name) r? @ghost

Rollup merge of #150151 - destabilise-target-spec-json, r=Kivooeo Destabilise `target-spec-json` Per rust-lang/compiler-team#944: > 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.

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

Open

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

davidtwco added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-blocked Status: Blocked on something else such as an RFC or other implementation work. labels Jan 12, 2026

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 Jan 12, 2026

JonathanBrouwer mentioned this pull request Jan 12, 2026

Rollup of 13 pull requests #151023

Closed

matthiaskrgr mentioned this pull request Jan 12, 2026

Rollup of 12 pull requests #151038

Closed

JonathanBrouwer mentioned this pull request Jan 13, 2026

Rollup of 14 pull requests #151051

Merged

rust-bors bot merged commit a89683d into rust-lang:main Jan 13, 2026
11 checks passed

rustbot added this to the 1.94.0 milestone Jan 13, 2026

davidtwco deleted the destabilise-target-spec-json branch January 14, 2026 14:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Destabilise `target-spec-json` #150151

Destabilise `target-spec-json` #150151

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!

davidtwco commented Jan 12, 2026

Uh oh!

rust-bors bot commented Jan 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Destabilise target-spec-json #150151

Destabilise target-spec-json #150151

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!

davidtwco commented Jan 12, 2026

Uh oh!

rust-bors bot commented Jan 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Destabilise `target-spec-json` #150151

Destabilise `target-spec-json` #150151

Kivooeo commented Dec 19, 2025 •

edited

Loading