Destabilise target-spec-json#150151
Conversation
|
These commits modify compiler targets. |
|
rustbot has assigned @JonathanBrouwer. Use |
|
r? me @bors r+ rollup |
…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.
…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
|
I don't see why exactly it fails, but the problem in |
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.
|
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.
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.
…uwer Rollup of 14 pull requests Successful merges: - rust-lang/rust#150151 (Destabilise `target-spec-json`) - rust-lang/rust#150826 (Add `f16` inline ASM support for s390x) - rust-lang/rust#150883 (Improve span for "unresolved intra doc link" on `deprecated` attribute) - rust-lang/rust#150934 (Move some checks from `check_doc_attrs` directly into `rustc_attr_parsing`) - rust-lang/rust#150943 (Port `#[must_not_suspend]` to attribute parser) - rust-lang/rust#150990 (std: sys: net: uefi: Make TcpStream Send) - rust-lang/rust#150995 (core: ptr: split_at_mut: fix typo in safety doc) - rust-lang/rust#150998 (Relax test expectation for @__llvm_profile_runtime_user) - rust-lang/rust#151002 (Remove a workaround for a bug (take 2)) - rust-lang/rust#151005 (Fix typo in `MaybeUninit` docs) - rust-lang/rust#151011 (Update books) - rust-lang/rust#151029 (rustc-dev-guide subtree update) - rust-lang/rust#151032 (fix: added missing backtick in triagebot.toml) - rust-lang/rust#151035 (Don't suggest replacing closure parameter with type name) r? @ghost
…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
…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
With the json target specification format destabilized in rust-lang/rust#150151, `-Zjson-target-spec` is needed for custom targets. This should resolve the CI failures seen in #1070
…c` feature JSON target specifications were destabilized in rust-lang/rust#150151
…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
…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
JSON target specifications were destabilized in rust-lang/rust#150151 and now require this additional flag
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
…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
…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
…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
|
So now we need to pass 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? |
Per rust-lang/compiler-team#944: