)]}'
{
  "commit": "31e12ee467f2ec3fbe65dda3a681dca3d01b1923",
  "tree": "109b8bf0dfff4b7f97c18c8d84cece7659555d6f",
  "parents": [
    "f5811a13ed4ba62f0c919eed1410bda1d4b7be11",
    "6da3077db9990dfb845a99315abb32a3bceba028"
  ],
  "author": {
    "name": "Jacob Pratt",
    "email": "jacob@jhpratt.dev",
    "time": "Fri Jul 31 22:25:12 2026 -0400"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Fri Jul 31 22:25:12 2026 -0400"
  },
  "message": "Rollup merge of #160124 - scottmcm:simd-count, r\u003doli-obk\n\nStructurally prevent zero-count `BackendRepr::SimdVector`s\n\nThis 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\n\nIronically I was inspired to do this as part of [looking at making `Simd\u003cT, 0\u003e` *work*](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/Allow.20N.3D.3D0.3F/with/613345298), but importantly if that\u0027s 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\u0027s not even clear what the LLVM type of that value would be).\n",
  "tree_diff": []
}