Structurally prevent zero-count `BackendRepr::SimdVector`s by scottmcm · Pull Request #160124 · rust-lang/rust

scottmcm · 2026-07-29T08:06:59Z

This is already supposed to be impossible in layout, but this emphasizes that better. This PR makes no behaviour changes; just BackendLaneCount instead of u64 in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html

Ironically I was inspired to do this as part of looking at making Simd<T, 0> work, but importantly if that's going to happen I think it should be BackendRepr::Memory like other ZSTs, not a BackendRepr::ScalarVector that would need to carry around a useless LLVM value in OperandValue::Immediate (where it's not even clear what the LLVM type of that value would be).

rustbot · 2026-07-29T08:07:02Z

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

rustbot · 2026-07-29T08:07:04Z

r? @mu001999

rustbot has assigned @mu001999.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 74 candidates
Random selection from 16 candidates

mu001999 · 2026-07-29T13:38:45Z

@rustbot reroll

rustbot · 2026-07-29T16:30:08Z

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

rustbot · 2026-07-30T05:19:29Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

oli-obk · 2026-07-30T13:59:34Z

+impl From<BackendLaneCount> for u32 {
+    fn from(c: BackendLaneCount) -> u32 {
+        c.0.get().into()
+    }
+}
+impl From<BackendLaneCount> for u64 {
+    fn from(c: BackendLaneCount) -> u64 {
+        c.0.get().into()
+    }
+}


Please make those explicit methods, I had to look up what the .into() calls were doing and if you're not getting any UX simplicity out of it, may as well make it very explicit

View changes since the review

Sounds good. I was torn between them.

This is already *supposed* to be impossible in layout, but this emphasizes that better. Ironically I was inspired to do this as part of looking at making `Simd<T, 0>` *work*, but importantly if that's going to happen I think it should be `BackendRepr::Memory` like other ZSTs, *not* a `BackendRepr::ScalarVector` that would need to carry around a useless LLVM value in `OperandValue::Immediate` (where it's not even clear what the LLVM type of that value would be).

rustbot · 2026-07-31T02:48:34Z

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

oli-obk · 2026-07-31T14:10:45Z

@bors r+

rust-bors · 2026-07-31T14:10:48Z

📌 Commit 6da3077 has been approved by oli-obk

It is now in the queue for this repository.

Structurally prevent zero-count `BackendRepr::SimdVector`s This is already *supposed* to be impossible in layout, but this emphasizes that better. This PR makes no behaviour changes; just `BackendLaneCount` instead of `u64` in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html Ironically I was inspired to do this as part of [looking at making `Simd<T, 0>` *work*](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/Allow.20N.3D.3D0.3F/with/613345298), but importantly if that's going to happen I think it should be `BackendRepr::Memory` like other ZSTs, *not* a `BackendRepr::ScalarVector` that would need to carry around a useless LLVM value in `OperandValue::Immediate` (where it's not even clear what the LLVM type of that value would be).

Rollup of 14 pull requests Successful merges: - #159245 (Emit retags in codegen to support BorrowSanitizer (part 5)) - #159864 (Report "capacity overflow" for oversized Rc<[T]>/Arc<[T]>) - #160079 (make atomic operations const) - #160124 (Structurally prevent zero-count `BackendRepr::SimdVector`s) - #160162 (Make `#[fundamental]` only apply to the first argument of `Box`) - #160210 (Remove an outdated FIXME) - #160282 (Improve diagnostic for patterns in function pointer types) - #157928 (Eagerly fetch typeck results when linting) - #159672 (Improve suggestions when multiples tuples implement the same trait) - #159861 (Add documentation for the `non_exhaustive` attribute) - #159907 (Fix `hidden_glob_reexports` in `rustc_ast`) - #159998 (Align expect messages with guidance) - #160145 (Expand checks for register_tool) - #160307 (Update `minifier` version to `0.4.0`)

Rollup merge of #160124 - scottmcm:simd-count, r=oli-obk Structurally prevent zero-count `BackendRepr::SimdVector`s This is already *supposed* to be impossible in layout, but this emphasizes that better. This PR makes no behaviour changes; just `BackendLaneCount` instead of `u64` in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.html Ironically I was inspired to do this as part of [looking at making `Simd<T, 0>` *work*](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/Allow.20N.3D.3D0.3F/with/613345298), but importantly if that's going to happen I think it should be `BackendRepr::Memory` like other ZSTs, *not* a `BackendRepr::ScalarVector` that would need to carry around a useless LLVM value in `OperandValue::Immediate` (where it's not even clear what the LLVM type of that value would be).

rustbot assigned mu001999 Jul 29, 2026

This comment has been minimized.

Sign in to view

programmerjake reviewed Jul 29, 2026

View reviewed changes

Comment thread compiler/rustc_abi/src/layout.rs

rustbot assigned oli-obk and unassigned mu001999 Jul 29, 2026

scottmcm force-pushed the simd-count branch from 9454ca4 to df5ae6b Compare July 29, 2026 16:30

rustbot added the T-clippy Relevant to the Clippy team. label Jul 29, 2026

This comment has been minimized.

Sign in to view

scottmcm force-pushed the simd-count branch from df5ae6b to 6d36965 Compare July 30, 2026 05:19

oli-obk requested changes Jul 30, 2026

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 30, 2026

scottmcm force-pushed the simd-count branch from 6d36965 to 6da3077 Compare July 31, 2026 02:48

scottmcm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 31, 2026

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 Jul 31, 2026

jhpratt mentioned this pull request Aug 1, 2026

Rollup of 16 pull requests #160308

Closed

This was referenced Aug 1, 2026

Rollup of 15 pull requests #160309

Closed

Rollup of 14 pull requests #160310

Merged

rust-bors Bot merged commit 31e12ee into rust-lang:main Aug 1, 2026
13 checks passed

rustbot added this to the 1.99.0 milestone Aug 1, 2026

Uh oh!

Uh oh!

Conversation

scottmcm commented Jul 29, 2026

Uh oh!

rustbot commented Jul 29, 2026

Uh oh!

rustbot commented Jul 29, 2026

Uh oh!

This comment has been minimized.

Uh oh!

mu001999 commented Jul 29, 2026

Uh oh!

rustbot commented Jul 29, 2026

Uh oh!

This comment has been minimized.

rustbot commented Jul 30, 2026

Uh oh!

oli-obk Jul 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

scottmcm Jul 31, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rustbot commented Jul 31, 2026

Uh oh!

oli-obk commented Jul 31, 2026

Uh oh!

rust-bors Bot commented Jul 31, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

oli-obk Jul 30, 2026 •

edited by rustbot

Loading