Skip to content

Destabilise target-spec-json #150151

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.

Sign up for GitHub

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

Jump to bottom
Open
davidtwco wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Destabilise target-spec-json #150151

davidtwco wants to merge 1 commit into from
+38 −8

Conversation

@davidtwco
Copy link
Member

@davidtwco davidtwco commented Dec 19, 2025

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.

@rustbot
Copy link
Collaborator

rustbot commented Dec 19, 2025

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

@rustbot 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
Copy link
Collaborator

rustbot commented Dec 19, 2025

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
Copy link
Member

Kivooeo commented Dec 19, 2025

r? me

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Dec 19, 2025

📌 Commit 6c4c438 has been approved by Kivooeo

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 Dec 19, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 19, 2025
@matthiaskrgr
Rollup merge of rust-lang#150151 - davidtwco:destabilise-target-spec-…
5572942 
…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.
@matthiaskrgr matthiaskrgr mentioned this pull request Dec 19, 2025
Closed
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 19, 2025
@matthiaskrgr
Rollup merge of rust-lang#150151 - davidtwco:destabilise-target-spec-…
fadc4fe 
…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.
@matthiaskrgr matthiaskrgr mentioned this pull request Dec 19, 2025
Closed
bors added a commit that referenced this pull request Dec 19, 2025
@bors
Auto merge of #150168 - matthiaskrgr:rollup-9xyda9w, r=matthiaskrgr
12cfbb4 
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
Copy link
Member

matthiaskrgr commented Dec 19, 2025

@bors r-
#150168 (comment)

@bors 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
@Kivooeo
Copy link
Member

Kivooeo commented Dec 19, 2025 •
edited
Loading

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

@Mark-Simulacrum Mark-Simulacrum added the relnotes Marks issues that should be documented in the release notes of the next release. label Dec 20, 2025
@rustbot rustbot mentioned this pull request Dec 20, 2025
Open
davidtwco added a commit to davidtwco/cargo that referenced this pull request Jan 5, 2026
@davidtwco
test: add -Zunstable-options with custom targets
54e6ac0 
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 davidtwco mentioned this pull request Jan 5, 2026
Merged
@davidtwco
Copy link
Member Author

davidtwco commented Jan 5, 2026

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

@davidtwco 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 a commit to davidtwco/cargo that referenced this pull request Jan 5, 2026
@davidtwco
test: add -Zunstable-options with custom targets
77eeca4 
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 added a commit to davidtwco/cargo that referenced this pull request Jan 5, 2026
@davidtwco
test: add -Zunstable-options with custom targets
b4ca49f 
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 added a commit to davidtwco/cargo that referenced this pull request Jan 6, 2026
@davidtwco
test: add -Zunstable-options with custom targets
f5064bb 
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.
github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Jan 6, 2026
@weihanglo
test: add -Zunstable-options with custom targets (#16467)
b53c96b 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@Kivooeo Kivooeo

Labels

A-run-make Area: port run-make Makefiles to rmake.rs relnotes Marks issues that should be documented in the release notes of the next release. S-blocked Status: Blocked on something else such as an RFC or other implementation work. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@davidtwco @rustbot @Kivooeo @bors @matthiaskrgr @Mark-Simulacrum @JonathanBrouwer