Skip to content

Conversation

Zalathar
Copy link
Contributor

@Zalathar Zalathar commented Sep 22, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

pthariensflame and others added 27 commits September 13, 2025 23:25
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>
…ark-Simulacrum regression test for Cow<[u8]> layout requested by ralf in rust-lang#117763 (comment)
…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!).
…parser, r=nnethercote Port `feature` to the new attribute system
…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 rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-compiletest Area: The compiletest test runner A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. labels Sep 22, 2025
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Sep 22, 2025
@Zalathar
Copy link
Contributor Author

@bors r+ rollup=never p=5

@rustbot rustbot added the rollup A PR which is a rollup label Sep 22, 2025
@bors
Copy link
Collaborator

bors commented Sep 22, 2025

📌 Commit 6335498 has been approved by Zalathar

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 Sep 22, 2025
@bors
Copy link
Collaborator

bors commented Sep 22, 2025

⌛ Testing commit 6335498 with merge 702aba1...

bors added a commit that referenced this pull request Sep 22, 2025
Rollup of 10 pull requests Successful merges: - #145411 (regression test for Cow<[u8]> layout) - #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) - #146652 (Port `feature` to the new attribute system) - #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
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-rust-for-linux failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
 CLIPPY samples/rust/rust_print_main.o CLIPPY drivers/net/phy/ax88796b_rust.o CLIPPY rust/doctests_kernel_generated.o thread 'rustc' (56855) panicked at /checkout/compiler/rustc_hir/src/hir.rs:1323:18: can't get the span of an arbitrary parsed attribute: Parsed(Feature([new_uninit#0], rust/doctests_kernel_generated.rs:5129:1: 5129:24 (#0))) stack backtrace: 0: __rustc::rust_begin_unwind 1: core::panicking::panic_fmt 2: clippy_lints::undocumented_unsafe_blocks::include_attrs_in_span 3: clippy_lints::undocumented_unsafe_blocks::stmt_has_safety_comment 4: <clippy_lints::undocumented_unsafe_blocks::UndocumentedUnsafeBlocks as rustc_lint::passes::LateLintPass>::check_block 5: <rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass> as rustc_hir::intravisit::Visitor>::visit_block 6: <rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass> as rustc_hir::intravisit::Visitor>::visit_expr::{closure#0} 7: <rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass> as rustc_hir::intravisit::Visitor>::visit_nested_body 8: <rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass> as rustc_hir::intravisit::Visitor>::visit_fn 9: rustc_hir::intravisit::walk_item::<rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass>> 10: <rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass> as rustc_hir::intravisit::Visitor>::visit_nested_item 11: <rustc_lint::late::LateContextAndPass<rustc_lint::late::RuntimeCombinedLateLintPass> as rustc_hir::intravisit::Visitor>::visit_mod 12: rustc_lint::late::late_lint_crate 13: rustc_lint::late::check_crate 14: <rustc_data_structures::sync::parallel::ParallelGuard>::run::<(), rustc_interface::passes::analysis::{closure#0}::{closure#1}::{closure#0}> 15: rustc_interface::passes::analysis [... omitted 2 frames ...] 16: <std::thread::local::LocalKey<core::cell::Cell<*const ()>>>::with::<rustc_middle::ty::context::tls::enter_context<<rustc_middle::ty::context::GlobalCtxt>::enter<rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2}::{closure#0}, core::option::Option<rustc_interface::queries::Linker>>::{closure#1}, core::option::Option<rustc_interface::queries::Linker>>::{closure#0}, core::option::Option<rustc_interface::queries::Linker>> 17: <rustc_middle::ty::context::TyCtxt>::create_global_ctxt::<core::option::Option<rustc_interface::queries::Linker>, rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2}::{closure#0}> 18: <rustc_interface::passes::create_and_enter_global_ctxt<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}>::{closure#2} as core::ops::function::FnOnce<(&rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2})>>::call_once::{shim:vtable#0} 19: <alloc::boxed::Box<dyn for<'a> core::ops::function::FnOnce<(&'a rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &'a std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt<'a>>, &'a rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena<'a>>, &'a rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena<'a>>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}), Output = core::option::Option<rustc_interface::queries::Linker>>> as core::ops::function::FnOnce<(&rustc_session::session::Session, rustc_middle::ty::context::CurrentGcx, alloc::sync::Arc<rustc_data_structures::jobserver::Proxy>, &std::sync::once_lock::OnceLock<rustc_middle::ty::context::GlobalCtxt>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_middle::arena::Arena>, &rustc_data_structures::sync::worker_local::WorkerLocal<rustc_hir::Arena>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2})>>::call_once 20: rustc_interface::passes::create_and_enter_global_ctxt::<core::option::Option<rustc_interface::queries::Linker>, rustc_driver_impl::run_compiler::{closure#0}::{closure#2}> 21: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::run_in_thread_with_globals<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<(), rustc_driver_impl::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}::{closure#0}, ()> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust-clippy/issues/new?template=ice.yml note: please make sure that you have updated to the latest nightly note: please attach the file at `/checkout/obj/rfl/linux/rustc-ice-2025-09-22T06_11_08-56854.txt` to your bug report note: compiler flags: -Z binary_dep_depinfo=y -C panic=abort -C embed-bitcode=n -C lto=n -C force-unwind-tables=n -C codegen-units=1 -C symbol-mangling-version=v0 -C relocation-model=static -Z function-sections=n -C target-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2 -Z cf-protection=branch -Z no-jump-tables -C target-cpu=x86-64 -Z tune-cpu=generic -C no-redzone=y -C code-model=kernel -Z function-return=thunk-extern -Z patchable-function-entry=16,16 -C opt-level=2 -C debug-assertions=n -C overflow-checks=y -Z allow-features=asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg -Z crate-attr=no_std -Z crate-attr=feature(asm_const,asm_goto,arbitrary_self_types,lint_reasons,offset_of_nested,raw_ref_op,used_with_arg) -Z unstable-options --crate-type rlib query stack during panic: #0 [analysis] running analysis passes on this crate end of query stack note: Clippy version: clippy 0.1.92 (702aba19c8 2025-09-22) make[3]: *** [scripts/Makefile.build:354: rust/doctests_kernel_generated.o] Error 101 make[2]: *** [scripts/Makefile.build:556: rust] Error 2 make[1]: *** [/checkout/obj/rfl/linux/Makefile:2011: .] Error 2 make: *** [Makefile:248: __sub-make] Error 2 make: Leaving directory '/checkout/obj/rfl/linux' local time: Mon Sep 22 06:11:14 UTC 2025 network time: Mon, 22 Sep 2025 06:11:14 GMT **************************************************************************** To find more information about this job, visit the following URL: 

For more information how to resolve CI failures of this job, visit this link.

@bors
Copy link
Collaborator

bors commented Sep 22, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 22, 2025
@Zalathar Zalathar closed this Sep 22, 2025
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 22, 2025
@Zalathar Zalathar deleted the rollup-u87iupw branch September 22, 2025 06:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-compiletest Area: The compiletest test runner A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.