Rollup of 8 pull requests #146871
Closed
Rollup of 8 pull requests #146871
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now that this feature has a standard identifier, Darwin has started exposing it accordingly, in addition to the existing less-standard way. Check both, and enable the `crc` feature if either identifier for it is present to ensure backwards and forwards compatibility.
Brings the list of checkable features up to date with the initial release of macOS 26 "Tahoe".
I can't really make sense of this part. For musl targets that default to static linkage, crt-static is set as a target feature and cc-rs should be able to correctly infer that -static should be used. However, you cannot compile rustc or run the tests with +crt-static, so you'd have to disable it in bootstrap.toml anyways, bypassing this codepath entirely. But for targets that are defaulting to dynamic linkage, hardcoding -static for all musl targets in cc_detect just doesn't make sense. It breaks the run-make tests because the compiler defaults (and is configured!) to dynamically link dylibs, but the cc-rs configuration is hardcoded to link them statically, which will fail. Signed-off-by: Jens Reidel <adrian@travitia.xyz>
I missed this target when I changed all the other tier 3 targets. Only realized that this one was still statically linked when I looked at the list of targets in the test later. Signed-off-by: Jens Reidel <adrian@travitia.xyz>
…nnethercote Add panic=immediate-abort MCP: rust-lang/compiler-team#909 This adds a new panic strategy, `-Cpanic=immediate-abort`. This panic strategy essentially just codifies use of `-Zbuild-std-features=panic_immediate_abort`. This PR is intended to just set up infrastructure, and while it will change how the compiler is invoked for users of the feature, there should be no other impacts. In many parts of the compiler, `PanicStrategy::ImmediateAbort` behaves just like `PanicStrategy::Abort`, because actually most parts of the compiler just mean to ask "can this unwind?" so I've added a helper function so we can say `sess.panic_strategy().unwinds()`. The panic and unwind strategies have some level of compatibility, which mostly means that we can pre-compile the sysroot with unwinding panics then the sysroot can be linked with aborting panics later. The immediate-abort strategy is all-or-nothing, enforced by `compiler/rustc_metadata/src/dependency_format.rs` and this is tested for in `tests/ui/panic-runtime/`. We could _technically_ be more compatible with the other panic strategies, but immediately-aborting panics primarily exist for users who want to eliminate all the code size responsible for the panic runtime. I'm open to other use cases if people want to present them, but not right now. This PR is already large. `-Cpanic=immediate-abort` sets both `cfg(panic = "immediate-abort")` _and_ `cfg(panic = "abort")`. bjorn3 pointed out that people may be checking for the abort cfg to ask if panics will unwind, and also the sysroot feature this is replacing used to require `-Cpanic=abort` so this seems like a good back-compat step. At least for the moment. Unclear if this is a good idea indefinitely. I can imagine this being confusing. The changes to the standard library attributes are purely mechanical. Apart from that, I removed an `unsafe` we haven't needed for a while since the `abort` intrinsic became safe, and I've added a helpful diagnostic for people trying to use the old feature. To test that `-Cpanic=immediate-abort` conflicts with other panic strategies, I've beefed up the core-stubs infrastructure a bit. There is now a separate attribute to set flags on it. I've added a test that this produces the desired codegen, called `tests/run-make-cargo/panic-immediate-abort-codegen/` and also a separate run-make-cargo test that checks that we can build a binary.
std_detect on Darwin AArch64: update features Synchronizes the list (and re-sorts it alphabetically by `FEAT` name) with the initial release version of macOS Tahoe.
…=Mark-Simulacrum bootstrap: Don't force -static for musl targets in cc-rs I can't really make sense of this part. For musl targets that default to static linkage, crt-static is set as a target feature and cc-rs should be able to correctly infer that -static should be used. However, you cannot compile rustc or run the tests with +crt-static, so you'd have to disable it in bootstrap.toml anyways, bypassing this codepath entirely. But for targets that are defaulting to dynamic linkage, hardcoding -static for all musl targets in cc_detect just doesn't make sense. It breaks the run-make tests because the compiler defaults (and is configured!) to dynamically link dylibs, but the cc-rs configuration is hardcoded to link them statically, which will fail. This fixes running `./x.py test --stage 2` on musl hosts that default to dynamic linkage and when not explicitly setting `crt-static = false` in bootstrap.toml (since that should be the default!).
…kic,joshtriplett emit attribute for readonly non-pure inline assembly fixes rust-lang#146761 Provide a better `MemoryEffects` to LLVM when an inline assembly block specifies `readonly` but not `pure`. That means that the assembly block may not perform any writes, but that there still may be side effects from its instructions. I haven't been able to find a case yet where this actually matters, though. So the test checks that the right attribute is applied, but the generated assembly is equivalent to not specifying `readonly` at all. r? `@nikic` cc `@Amanieu`
Support ctr and lr as clobber-only registers in PowerPC inline assembly Follow-up to rust-lang#131341. CTR and LR are marked as volatile in all ABIs, but I skipped them in rust-lang#131341 due to they are currently marked as reserved. https://github.com/rust-lang/rust/blob/dd7fda570040e8a736f7d8bc28ddd1b444aabc82/compiler/rustc_target/src/asm/powerpc.rs#L209-L212 However, they are actually only unusable as input/output of inline assembly, and should be fine to support as clobber-only registers as discussed in [#t-compiler > ppc/ppc64 inline asm support](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/ppc.2Fppc64.20inline.20asm.20support/with/540413845). r? `@Amanieu` or `@workingjubilee` cc `@programmerjake` `@rustbot` label +O-PowerPC +A-inline-assembly
…olbinarycat Introduce "wrapper" helpers to rustdoc Add a few traits for streamlining places where we need to wrap certain `fmt::Display`s in stuff like parentheses or brackets. Hopefully this makes the actual display logic slightly easier to read. First two commits are small, unrelated cleanups. I'll probably add some doc comments to the stuff in `display.rs`, maybe also play around with the API, but wanted to get feedback on this idea first.
btree InternalNode::new safety comments
…=jieyouxu Make mips64el-unknown-linux-muslabi64 link dynamically I missed this target when I changed all the other tier 3 targets in rust-lang#144410. Only realized that this one was still statically linked when I looked at the list of targets in the test later (rust-lang#146588). since those two PRs were reviewed by you: r? `@jieyouxu`
rustbot
added
A-compiletest
rustbot
added
T-rustdoc
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Sep 22, 2025
Rollup of 8 pull requests Successful merges: - #146317 (Add panic=immediate-abort) - #146397 (std_detect on Darwin AArch64: update features) - #146594 (bootstrap: Don't force -static for musl targets in cc-rs) - #146791 (emit attribute for readonly non-pure inline assembly) - #146831 (Support ctr and lr as clobber-only registers in PowerPC inline assembly) - #146838 (Introduce "wrapper" helpers to rustdoc) - #146846 (btree InternalNode::new safety comments) - #146858 (Make mips64el-unknown-linux-muslabi64 link dynamically) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Looks flaky, but I'll take this opportunity to make a larger rollup. |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup