target: fix destabilising target-spec-json by davidtwco · Pull Request #151534 · rust-lang/rust

davidtwco · 2026-01-23T11:12:42Z

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

rustbot · 2026-01-23T11:12:46Z

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

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.

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`).

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 · 2026-01-26T15:01:05Z

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

ehuss · 2026-01-26T15:26:07Z

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

chenyukang · 2026-01-27T03:28:55Z

@bors r=chenyukang

rust-bors · 2026-01-27T03:28:58Z

📌 Commit 76b6623 has been approved by chenyukang

It is now in the queue for this repository.

…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 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 · 2026-01-27T06:36:02Z

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

@bors r-

rust-bors · 2026-01-27T06:36:06Z

Commit 76b6623 has been unapproved.

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

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>

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

Post-January 2026 nightly builds destabilized custom JSON target specs (rust-lang/rust#151534), requiring an explicit -Zjson-target-spec flag when passing a .json path to cargo --target. Without this, cargo-psp fails with "`.json` target specs require -Zjson-target-spec" in CI. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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).

* Add SDK platform abstractions: sync, cache, DMA, VFPU math, audio mixer, framebuffer, memory Push reusable platform infrastructure into the SDK so every project benefits: - psp::sync — Extract SpinMutex from debug.rs, add SpinRwLock, SPSC ring buffer, UncachedBox<T> - psp::cache — Type-safe CachedPtr/UncachedPtr with flush/invalidate conversions - psp::me::MeExecutor — High-level ME task submission with poll/wait and shared uncached state - psp::dma — DmaTransfer handle with memcpy_dma/vram_blit_dma and sceDmac syscall bindings - psp::simd — VFPU-accelerated Vec4/Mat4 math, color ops, easing functions - psp::audio_mixer — Multi-channel PCM mixer with volume/panning/fade - psp::framebuffer — DoubleBuffer, DirtyRect tracking, LayerCompositor - psp::mem — Typed partition allocators (Partition2Alloc/Partition3Alloc) preventing ME pointer misuse Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add Phase 2 SDK abstractions: io, thread, input, time + Phase 1 bugfixes Bugfixes: - Fix MeExecutor::submit() race condition by storing real_task/real_arg in dedicated MeSharedState fields instead of double-writing boot_params - Fix audio_mixer volume mixing i32 overflow by using i64 intermediates - Document sceDmacMemcpy synchronous behavior in dma.rs - Remove unnecessary blanket #![allow(unsafe_op_in_unsafe_fn)] from simd.rs New modules: - psp::io - File (RAII), ReadDir iterator, read_to_vec, write_bytes, stat, create_dir, remove_file, remove_dir, rename - psp::thread - ThreadBuilder, JoinHandle, spawn() with closure trampoline, sleep_ms, current_thread_id - psp::input - Controller with press/release detection, analog deadzone - psp::time - Instant, Duration, DateTime, FrameTimer Enhanced modules: - psp::sync - Add Semaphore and EventFlag kernel primitive wrappers Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add Phase 3 SDK abstractions: display, power, audio, dialog, net, wlan, callback + bugfixes Code review fixes: - Wrap thread trampoline in catch_unwind for panic safety - Simplify DmaTransfer to DmaResult (remove fake async API) - Add #[repr(C, align(64))] to MeSharedState for cache coherency - Document DoubleBuffer::new() init requirement - Add vec4_length and vec4_distance to VFPU simd module New SDK modules: - psp::display - vblank sync, framebuffer get/set - psp::power - clock control, battery info, AC detection - psp::audio - AudioChannel with RAII reserve/release - psp::callback - one-call exit callback setup - psp::dialog - blocking message/confirm/error dialogs - psp::wlan - WiFi hardware status - psp::net - init/term, AP connect, TcpStream, UdpSocket, DNS resolve Update examples to use new SDK modules: - clock-speed, file-io, time, wlan, audio-tone, msg-dialog Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add Phase 4 SDK abstractions: gu_ext, timer, usb, config, image, font + power extensions New modules: - psp::gu_ext — GU state snapshot/restore, 2D setup, SpriteVertex, SpriteBatch - psp::timer — Alarm (one-shot closure trampoline) and VTimer (RAII wrapper) - psp::usb — USB bus control and UsbStorageMode (RAII mass storage) - psp::config — Binary key-value config persistence (RCFG format) - psp::image — Hardware JPEG decode (sceJpeg*) and software BMP 24/32-bit decode - psp::font — FontLib, Font, FontRenderer with VRAM glyph atlas (PsmT8 + CLUT) Extended: - psp::power — on_power_event (RAII callback), prevent_sleep, prevent_display_off Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add 6 SDK showcase examples and expand README Platform SDK docs New examples demonstrating Phase 1-4 SDK modules: thread-sync (SpinMutex + spawn), input-analog (Controller deadzone), config-save (RCFG format), timer-alarm (Alarm + VTimer), net-http (WiFi + TcpStream), system-font (FontLib + FontRenderer + GU). README revised: "High-Level Utilities" replaced with comprehensive "Platform SDK" section (30+ modules in 9 domain categories), examples table updated with 6 new entries, structure description updated. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add Phase 5 SDK hardening: soundness fixes, correctness improvements, 6 new modules Critical soundness fixes: UncachedBox Drop now calls drop_in_place, SpscQueue Drop drains remaining items, PartitionAlloc tracks initialization state to prevent UB on uninit Drop, Alarm restructured with AtomicU8 state machine to eliminate interrupt-context allocation and TOCTOU race between Drop and trampoline. Medium correctness fixes: JoinHandle::join returns thread exit status, dialog/connect_ap polling timeouts, config serialize overflow checks, power callback cleanup on failure, callback registration error check, audio mixer volume saturation, glyph atlas eviction bounds, SpriteBatch dcache flush, sleep_ms overflow protection, removed dead mixer code. Low-priority improvements: cached tick resolution const, deprecated enable_home_button, Default impls, null-termination asserts, doc fixes, remapf division-by-zero guard. New modules: psp::http (RAII HTTP client), psp::mp3 (hardware MP3 decoder), psp::osk (on-screen keyboard), psp::rtc (extended RTC operations), psp::savedata (system save/load dialog), psp::system_param (system settings). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Replace deprecated enable_home_button() with setup_exit_callback() across all examples, add 4 new SDK examples Migrate all 26 existing examples from the deprecated psp::enable_home_button() to psp::callback::setup_exit_callback().unwrap(). Add 4 new examples showcasing Phase 5 SDK modules: http-client (psp::http), savedata (psp::savedata), osk-input (psp::osk), and rtc-sysinfo (psp::rtc + psp::system_param). Update README code snippets and examples table accordingly. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Fix CI: add -Zjson-target-spec for newer nightly toolchains Post-January 2026 nightly builds destabilized custom JSON target specs (rust-lang/rust#151534), requiring an explicit -Zjson-target-spec flag when passing a .json path to cargo --target. Without this, cargo-psp fails with "`.json` target specs require -Zjson-target-spec" in CI. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Fix soundness and correctness issues from AI code review - audio.rs: Validate buffer length in safe output_blocking/output_blocking_panning functions to prevent out-of-bounds reads by the PSP audio hardware. Store AudioFormat on AudioChannel to compute required buffer size. - audio_mixer.rs: Fix fade_out/fade_in duration capping at 256 frames by switching fade_level/fade_step to 16.16 fixed-point arithmetic, allowing accurate fades of any duration. - power.rs: Delete callback UID via sceKernelDeleteCallback on drop to prevent kernel resource leaks. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Fix CI: add pre-checkout cleanup to all workflow jobs The gemini-review, codex-review, agent-review-response, agent-failure-handler (pr-validation.yml) and create-release (main-ci.yml) jobs were missing pre-checkout cleanup. When the ci job runs Docker containers that create root-owned files in outputs/, subsequent jobs fail with EACCES when actions/checkout tries to clean the workspace. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: address AI review feedback (iteration 2) Automated fix by Claude in response to Gemini/Codex review. Iteration: 2/5 Co-Authored-By: AI Review Agent <noreply@anthropic.com> * fix: address AI review feedback (iteration 3) - Fix JoinHandle::drop double-free: check thread completion via sceKernelWaitThreadEnd before deciding whether to free the closure. Previously, dropping an unjoined handle for a thread that already finished would double-free the closure (trampoline freed it, then drop freed it again). - Fix audio mixer 1-sample silence gap on loop: remove `continue` after resetting position to 0, so the current output frame reads from position 0 instead of being skipped. - Replace unsafe transmute with TryFromPrimitive in system_param: language(), date_format(), and time_format() now use safe try_from() conversion instead of transmute, preventing UB if firmware returns an unexpected enum value. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: eliminate JoinHandle double-free race via shared ThreadPayload Replace the raw closure pointer with a ThreadPayload struct containing the closure and an AtomicBool flag. The trampoline sets the flag after consuming the closure, and Drop checks it after terminating the thread. This eliminates the race where a thread finishes between the zero-timeout wait check and sceKernelTerminateDeleteThread, which previously caused a double-free. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: validate thread name null termination in spawn_inner Both Gemini and Codex flagged that safe code could pass a non-null-terminated byte slice to sceKernelCreateThread, causing the kernel to read past the buffer. Add validation that name ends with \0 before proceeding. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: validate stereo buffer length parity in submit_samples Reject odd-length buffers in submit_samples to prevent an out-of-bounds panic when the mixing loop reads stereo pairs (L,R) from a looping channel that wraps around on a buffer with non-even length. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: AI Agent Bot <ai-agent@localhost> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: AI Review Agent <ai-review-agent@localhost>

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] Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206204535.39431-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

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

rustbot assigned chenyukang Jan 23, 2026

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 added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 23, 2026

This comment has been minimized.

Sign in to view

ehuss mentioned this pull request Jan 23, 2026

Tracking Issue for target-spec-json (flexible target specifications) #151528

Open

4 tasks

ehuss mentioned this pull request Jan 25, 2026

Add -Z json-target-spec rust-lang/cargo#16557

Merged

target: fix destabilising target-spec-json

76b6623

davidtwco force-pushed the destabilise-target-spec-json-again branch from ad34ef3 to 76b6623 Compare January 26, 2026 12:08

This comment has been minimized.

Sign in to view

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 mentioned this pull request Jan 27, 2026

Rollup of 3 pull requests #151721

Closed

Zalathar mentioned this pull request Jan 27, 2026

Rollup of 4 pull requests #151722

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

rust-bors bot merged commit 841c462 into rust-lang:main Feb 4, 2026
11 checks passed

rustbot added this to the 1.95.0 milestone Feb 4, 2026

davidtwco deleted the destabilise-target-spec-json-again branch February 5, 2026 15:30

davidtwco mentioned this pull request Feb 6, 2026

compiletest: -Zunstable-options for json targets #152236

Merged

github-actions bot mentioned this pull request Feb 10, 2026

Toolchain upgrade to nightly-2026-02-07 flux-rs/flux#1345

Open

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

Open

ehuss added the relnotes Marks issues that should be documented in the release notes of the next release. label Feb 16, 2026

rustbot mentioned this pull request Feb 16, 2026

Tracking issue for release notes of #151534: target: fix destabilising target-spec-json #152723

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

target: fix destabilising target-spec-json#151534

target: fix destabilising target-spec-json#151534
rust-bors[bot] merged 2 commits intorust-lang:mainfrom
davidtwco:destabilise-target-spec-json-again

davidtwco commented Jan 23, 2026 •

edited by ehuss

Loading

Uh oh!

rustbot commented Jan 23, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

davidtwco commented Jan 26, 2026

Uh oh!

ehuss commented Jan 26, 2026

Uh oh!

chenyukang commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

Zalathar commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Uh oh!

Conversation

davidtwco commented Jan 23, 2026 • edited by ehuss Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 23, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

davidtwco commented Jan 26, 2026

Uh oh!

ehuss commented Jan 26, 2026

Uh oh!

chenyukang commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

Zalathar commented Jan 27, 2026

Uh oh!

rust-bors bot commented Jan 27, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

davidtwco commented Jan 23, 2026 •

edited by ehuss

Loading