Skip to content

target: fix destabilising target-spec-json #151534

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 2 commits into
base: main
Choose a base branch
from
Open

target: fix destabilising target-spec-json #151534

davidtwco wants to merge 2 commits into from
+28 −7

Conversation

@davidtwco
Copy link
Member

@davidtwco davidtwco commented Jan 23, 2026 •
edited by ehuss
Loading

cc #151528

#150151 missed a case and didn't entirely destabilise target-spec-json - this patch corrects that.

Closes #71009

@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. labels Jan 23, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 23, 2026

r? @chenyukang

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

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 23, 2026
@rust-log-analyzer

This comment has been minimized.

Sign in to view
@ehuss ehuss mentioned this pull request Jan 23, 2026
Open
4 tasks
ehuss added a commit to ehuss/cargo that referenced this pull request Jan 25, 2026
@ehuss
Add -Z json-target-spec
6fc4eaa 
This adds the `-Z json-target-spec` CLI flag to assist with using custom
`.json` target spec files. `rustc` recently switched so that it requires
`-Z unstable-options` when using custom spec files
(rust-lang/rust#151534). This can make it rather
awkward to use spec files with cargo because it then requires setting
RUSTFLAGS and RUSTDOCFLAGS to pass `-Zunstable-options`. It also ends up
causing some confusing error messages.

Now, using `--target` with `.json` extension files generates an error
that explains you need `-Zjson-target-spec`. The only thing this flag
does is disable that error, and automatically passes
`-Zunstable-options` with the `--target` flag.

This does not 100% cover json target spec files, because they can be
placed in RUST_TARGET_PATH or the sysroot, and `rustc` will
automatically search for them (without the `.json` extension in the
`--target` arg). The user will just need to use RUSTFLAGS/RUSTDOCFLAGS
in that situation (but I expect that to be rare).

The majority of this change is changing `CompileTarget::new` to take a
flag if `-Zjson-target-spec` is enabled, and then threading through all
the places that call it. `CompileTarget::new` is responsible for
generating an error if json is used without the Z flag.
ehuss added a commit to ehuss/cargo that referenced this pull request Jan 25, 2026
@ehuss
Add -Z json-target-spec
b78dc10 
This adds the `-Z json-target-spec` CLI flag to assist with using custom
`.json` target spec files. `rustc` recently switched so that it requires
`-Z unstable-options` when using custom spec files
(rust-lang/rust#151534). This can make it rather
awkward to use spec files with cargo because it then requires setting
RUSTFLAGS and RUSTDOCFLAGS to pass `-Zunstable-options`. It also ends up
causing some confusing error messages.

Now, using `--target` with `.json` extension files generates an error
that explains you need `-Zjson-target-spec`. The only thing this flag
does is disable that error, and automatically passes
`-Zunstable-options` with the `--target` flag.

This does not 100% cover json target spec files, because they can be
placed in RUST_TARGET_PATH or the sysroot, and `rustc` will
automatically search for them (without the `.json` extension in the
`--target` arg). The user will just need to use RUSTFLAGS/RUSTDOCFLAGS
in that situation (but I expect that to be rare).

The majority of this change is changing `CompileTarget::new` to take a
flag if `-Zjson-target-spec` is enabled, and then threading through all
the places that call it. `CompileTarget::new` is responsible for
generating an error if json is used without the Z flag.
@ehuss ehuss mentioned this pull request Jan 25, 2026
Merged
github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Jan 25, 2026
@epage
Add -Z json-target-spec (#16557)
3a1b3fc 
This adds the `-Z json-target-spec` CLI flag to assist with using custom
`.json` target spec files. `rustc` recently switched so that it requires
`-Z unstable-options` when using custom spec files
(rust-lang/rust#151534). This can make it rather
awkward to use spec files with cargo because it then requires setting
RUSTFLAGS and RUSTDOCFLAGS to pass `-Zunstable-options`. It also ends up
causing some confusing error messages.

See the individual commits for more details.

This ended up being a larger diff than I wanted. I'm not 100% certain
this is worth it, but I think it significantly improves the experience
using `.json` files, so I I'm leaning towards it.

### How to test and review this PR?

Testing can be done with `rustc` built from
rust-lang/rust#151534 to ensure that everything
passes after that PR (including setting `CARGO_RUN_BUILD_STD_TESTS=1`).
ranger-ross pushed a commit to ranger-ross/cargo that referenced this pull request Jan 25, 2026
@epage @ranger-ross
Add -Z json-target-spec (rust-lang#16557)
cd39acf 
This adds the `-Z json-target-spec` CLI flag to assist with using custom
`.json` target spec files. `rustc` recently switched so that it requires
`-Z unstable-options` when using custom spec files
(rust-lang/rust#151534). This can make it rather
awkward to use spec files with cargo because it then requires setting
RUSTFLAGS and RUSTDOCFLAGS to pass `-Zunstable-options`. It also ends up
causing some confusing error messages.

See the individual commits for more details.

This ended up being a larger diff than I wanted. I'm not 100% certain
this is worth it, but I think it significantly improves the experience
using `.json` files, so I I'm leaning towards it.

Testing can be done with `rustc` built from
rust-lang/rust#151534 to ensure that everything
passes after that PR (including setting `CARGO_RUN_BUILD_STD_TESTS=1`).
@davidtwco davidtwco force-pushed the destabilise-target-spec-json-again branch from ad34ef3 to 76b6623 Compare January 26, 2026 12:08
@rust-log-analyzer

This comment has been minimized.

Sign in to view
@davidtwco
Copy link
Member Author

davidtwco commented Jan 26, 2026

I'm at a loss for how this could be impacting the rustdoc-gui tests

@ehuss
Copy link
Contributor

ehuss commented Jan 26, 2026

The GUI tests have been failing frequently lately, see #93784.

@chenyukang
Copy link
Member

chenyukang commented Jan 27, 2026

@bors r=chenyukang

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 27, 2026

📌 Commit 76b6623 has been approved by chenyukang

It is now in the queue for this repository.

@rust-bors 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 27, 2026
Zalathar added a commit to Zalathar/rust that referenced this pull request Jan 27, 2026
@Zalathar
Rollup merge of rust-lang#151534 - davidtwco:destabilise-target-spec-…
4615453 
…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
@Zalathar Zalathar mentioned this pull request Jan 27, 2026
Closed
Zalathar added a commit to Zalathar/rust that referenced this pull request Jan 27, 2026
@Zalathar
Rollup merge of rust-lang#151534 - davidtwco:destabilise-target-spec-…
949ee62 
…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
@Zalathar Zalathar mentioned this pull request Jan 27, 2026
Closed
rust-bors bot pushed a commit that referenced this pull request Jan 27, 2026
@bors
Auto merge of #151722 - Zalathar:rollup-0Ec7izb, r=Zalathar
2003080 
Rollup of 4 pull requests

Successful merges:

 - #147436 (slice/ascii: Optimize `eq_ignore_ascii_case` with auto-vectorization)
 - #151390 (Reintroduce `QueryStackFrame` split.)
 - #151534 (target: fix destabilising target-spec-json)
 - #151692 (Try to reduce rustdoc GUI tests flakyness)
@Zalathar
Copy link
Member

Zalathar commented Jan 27, 2026

Failed in rollup in x86_64-rust-for-linux: #151722 (comment)

@bors r-

@rust-bors 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 Jan 27, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 27, 2026

Commit 76b6623 has been unapproved.

@davidtwco
Copy link
Member Author

davidtwco commented Jan 27, 2026

That makes sense, this will require disabling that job, pushed a commit to do that. We're destabilising custom targets to allow us to move forward with build-std without accidentally exposing functionality that we'd like to revisit prior to committing to. I'll start a thread on Zulip to discuss with the RfL team how we can come up with an alternative for them.

@rustbot ping rfl

@rustbot rustbot added the A-rust-for-linux Relevant for the Rust-for-Linux project label Jan 27, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 27, 2026

Hey Rust for Linux group! It looks like something broke the Rust for Linux integration.
Could you try to take a look?
In case it's useful, here are some instructions for tackling these sorts of issues.

cc @alex @BennoLossin @bjorn3 @dakr @Darksonn @dingxiangfei2009 @fbq @maurer @metaspace @nbdd0121 @ojeda @tgross35 @vincenzopalazzo

@ojeda
Copy link
Contributor

ojeda commented Jan 27, 2026

I would prefer to avoid disabling the job and instead I can give you a commit that adds -Zunstable-options.

@davidtwco
Copy link
Member Author

davidtwco commented Jan 27, 2026

Whatever works for you, I don't mind

#rust-for-linux > destabilising custom targets has the aforementioned Zulip discussion

@ojeda
Copy link
Contributor

ojeda commented Jan 27, 2026

Thanks! I will send it later today then.

ojeda added a commit to Rust-for-Linux/linux that referenced this pull request Jan 27, 2026
@ojeda
rust: kbuild: pass -Zunstable-options for Rust 1.95.0
0b5c7b0 
Custom target specifications are unstable, but starting with Rust 1.95.0,
`rustc` requires to explicitly pass `-Zunstable-options` to use them [1]:

    error: error loading target specification: custom targets are unstable and require `-Zunstable-options`
      |
      = help: run `rustc --print target-list` for a list of built-in targets

David (Rust compiler team lead), writes:

   "We're destabilising custom targets to allow us to move forward with
    build-std without accidentally exposing functionality that we'd like
    to revisit prior to committing to. I'll start a thread on Zulip to
    discuss with the RfL team how we can come up with an alternative
    for them."

Thus pass it.

Cc: David Wood <david@davidtw.co>
Cc: Wesley Wiser <wwiser@gmail.com>
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: rust-lang/rust#151534 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda added a commit to Rust-for-Linux/linux that referenced this pull request Jan 27, 2026
@ojeda
rust: kbuild: pass -Zunstable-options for Rust 1.95.0
eb268c7 
Custom target specifications are unstable, but starting with Rust 1.95.0,
`rustc` requires to explicitly pass `-Zunstable-options` to use them [1]:

    error: error loading target specification: custom targets are unstable and require `-Zunstable-options`
      |
      = help: run `rustc --print target-list` for a list of built-in targets

David (Rust compiler team lead), writes:

   "We're destabilising custom targets to allow us to move forward with
    build-std without accidentally exposing functionality that we'd like
    to revisit prior to committing to. I'll start a thread on Zulip to
    discuss with the RfL team how we can come up with an alternative
    for them."

Thus pass it.

Cc: David Wood <david@davidtw.co>
Cc: Wesley Wiser <wwiser@gmail.com>
Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
Link: rust-lang/rust#151534 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
ojeda added a commit to ojeda/rust that referenced this pull request Jan 27, 2026
@ojeda
CI: rfl: move to temporary commit to pass -Zunstable-options for cu…
c8656b7 
…stom target specs

This also takes the chance to move forward the job to Linux v6.19-rc7,
thus the previous workaround is not needed anymore.

Link: rust-lang#151534
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
@ojeda
Copy link
Contributor

ojeda commented Jan 27, 2026

Done -- could you please cherry-pick ojeda@c8656b7?

I tested locally with your compiler branch, let's see if it works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@chenyukang chenyukang

Labels

A-run-make Area: port run-make Makefiles to rmake.rs A-rust-for-linux Relevant for the Rust-for-Linux project S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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.

De-stabilize target spec JSON

7 participants

@davidtwco @rustbot @rust-log-analyzer @ehuss @chenyukang @Zalathar @ojeda