)]}'
{
  "commit": "467985700201bb28d01d40ff87f15fdd79b4e3fd",
  "tree": "c831c5bf47906e130be331a963802975549592ca",
  "parents": [
    "80c5ce687ba4ba4df405bcd7d3c3730ce2e7350b",
    "f771946e61c6728b1d2a2c45272d0d4740ba61d4"
  ],
  "author": {
    "name": "Jonathan Brouwer",
    "email": "jonathantbrouwer@gmail.com",
    "time": "Tue Sep 01 21:26:16 2026 +0200"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Tue Sep 01 21:26:16 2026 +0200"
  },
  "message": "Rollup merge of #161209 - scottmcm:redo-npot, r\u003dclarfonthey\n\nRework `next_power_of_two` to always be `1 \u003c\u003c …`\n\nr? @clarfonthey\nWho accidentally nerd-sniped me by mentioning rust-lang/rust#161069\n\nThis obviates that PR by reworking the `(checked_)next_power_of_two` logic to calculate the necessary exponent e, then return 2ᵉ, so it\u0027s structurally obvious from the IR -- the `shl nuw 1, …` instruction -- that it\u0027s always a power of two.\n\nAs always, the reason this is tricky is because shifts don\u0027t work for `\u003c\u003c Self::BITS`.  The previous code handled that by checking `self \u003c\u003d 1` first, and thus doing a `-1 \u003e\u003e n` where `n \u003c BITS`.  This code instead flips the check: it looks up-front for a value that will wrap (an input above `1 \u003c\u003c (BITS - 1)`) and thus by excluding those cases the calculated `1 \u003c\u003c n` always has `n \u003c BITS`.  And the codegen tests show that, without needing any `llvm.assume`s, LLVM can take advantage of it to do things like rewriting `%` to masking.  Plus the overflow check optimizes out for constrained inputs like slice lengths.\n",
  "tree_diff": []
}