https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=cargo_update 2025-09-25T10:31:53+00:00 2025-09-25T10:31:53+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-25T10:31:53+00:00 urn:sha1:fab06469ee33664739620ede53ed18b8c3c40644 Add an attribute to check the number of lanes in a SIMD vector after monomorphization Allows std::simd to drop the `LaneCount<N>: SupportedLaneCount` trait and maintain good error messages. Also, extends rust-lang/rust#145967 by including spans in layout errors for all ADTs. r? ``@RalfJung`` cc ``@workingjubilee`` ``@programmerjake`` 2025-09-24T00:47:34+00:00 Caleb Zulawski caleb.zulawski@gmail.com 2025-09-16T06:23:24+00:00 urn:sha1:f5c6c9542ecfab74e654f9b7f1150d486560ae43 Unify zero-length and oversized SIMD errors 2025-09-23T06:37:03+00:00 bors bors@rust-lang.org 2025-09-23T06:37:03+00:00 urn:sha1:40560823602064f4c726aea3e15e104449e1a392 Add panic=immediate-abort MCP: https://github.com/rust-lang/compiler-team/issues/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. 2025-09-21T17:12:18+00:00 Ben Kimock kimockb@gmail.com 2025-09-07T16:31:35+00:00 urn:sha1:888679013d1f424adef06267f3630069b4cabd40 2025-09-21T04:48:22+00:00 Taiki Endo te316e89@gmail.com 2025-09-21T04:48:22+00:00 urn:sha1:f4b876867d609404be8a78220c0d5117303bb0f8 2025-09-12T14:49:41+00:00 Zachary S zasample18+github@gmail.com 2025-09-12T14:49:41+00:00 urn:sha1:baed55cceffaa3b5dd0754436b413fa9aef544af 2025-09-10T12:17:38+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-10T12:17:38+00:00 urn:sha1:422c76adae98b55d13a07a8fb47d8bc47fa96fdf Implement `#[rustc_align_static(N)]` on `static`s Tracking issue: https://github.com/rust-lang/rust/issues/146177 ```rust #![feature(static_align)] #[rustc_align_static(64)] static SO_ALIGNED: u64 = 0; ``` We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`. r? `@traviscross` 2025-09-09T19:54:54+00:00 Folkert de Vries folkert@folkertdev.nl 2025-06-07T20:56:22+00:00 urn:sha1:cbacd00f106778830803ad2e2364518f06ff9078 We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`. 2025-09-09T12:49:16+00:00 Boxy rust@boxyuwu.dev 2025-08-21T15:50:54+00:00 urn:sha1:e379c7758667f900aaf5551c4553c7d4c121e3e1 2025-09-06T18:37:23+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-09-04T15:16:55+00:00 urn:sha1:f2933b34a8331204270fa2bdbdcfd79fcffbb302 It is always false nowadays. ThinLTO summary writing is instead done by llvm_optimize.