)]}'
{
  "commit": "6159a44067ebce42b38f062cc7df267a1348e092",
  "tree": "c0e34b3d88a2d299ff2af07466c3cde635cf309a",
  "parents": [
    "7c2c3c0ded2de378bfab2f5b55c387c66fbaf353",
    "b41c2a28705bb1b5d6c93d67f1eb24af210ea426"
  ],
  "author": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Wed Nov 19 02:23:56 2025 +0000"
  },
  "committer": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Wed Nov 19 02:23:56 2025 +0000"
  },
  "message": "Auto merge of #148434 - oli-obk:inherent-const-impl, r\u003dfee1-dead\n\nInherent const impl\n\nSome constifications are annoying because we need to repeat `T: Trait` bounds from an impl block on the individual constified `const fn`s as `T: [const] Trait`. We\u0027ve brainstormed solutions before, and one would be to have separate `const impl` blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.\n\nAlso interacts with the discussion around `impl const Trait for Type` vs `const impl Trait for Type`, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).\n\n* [ ] rustdoc + tests\n* [ ] macro stability /regression tests\n\nr? `@fee1-dead`\n\ncc `@traviscross` `@rust-lang/project-const-traits`\n",
  "tree_diff": []
}