Structurally prevent zero-count BackendRepr::SimdVectors - #160124
Conversation
|
r? @mu001999 rustbot has assigned @mu001999. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
|
@rustbot reroll |
|
cc @rust-lang/clippy
|
This comment has been minimized.
This comment has been minimized.
|
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. |
| 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() | ||
| } | ||
| } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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).
|
cc @bjorn3 |
|
@bors r+ |
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).
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).
Rollup of 14 pull requests Successful merges: - rust-lang/rust#159245 (Emit retags in codegen to support BorrowSanitizer (part 5)) - rust-lang/rust#159864 (Report "capacity overflow" for oversized Rc<[T]>/Arc<[T]>) - rust-lang/rust#160079 (make atomic operations const) - rust-lang/rust#160124 (Structurally prevent zero-count `BackendRepr::SimdVector`s) - rust-lang/rust#160162 (Make `#[fundamental]` only apply to the first argument of `Box`) - rust-lang/rust#160210 (Remove an outdated FIXME) - rust-lang/rust#160282 (Improve diagnostic for patterns in function pointer types) - rust-lang/rust#157928 (Eagerly fetch typeck results when linting) - rust-lang/rust#159672 (Improve suggestions when multiples tuples implement the same trait) - rust-lang/rust#159861 (Add documentation for the `non_exhaustive` attribute) - rust-lang/rust#159907 (Fix `hidden_glob_reexports` in `rustc_ast`) - rust-lang/rust#159998 (Align expect messages with guidance) - rust-lang/rust#160145 (Expand checks for register_tool) - rust-lang/rust#160307 (Update `minifier` version to `0.4.0`)
This is already supposed to be impossible in layout, but this emphasizes that better. This PR makes no behaviour changes; just
BackendLaneCountinstead ofu64in https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.BackendRepr.htmlIronically 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 beBackendRepr::Memorylike other ZSTs, not aBackendRepr::ScalarVectorthat would need to carry around a useless LLVM value inOperandValue::Immediate(where it's not even clear what the LLVM type of that value would be).