)]}'
{
  "commit": "3b4e355a0a23ccffee9fe3f0d4f70fb4fbc84982",
  "tree": "2a481b873d57f79ea9d07a4dac498994b05fd698",
  "parents": [
    "af041c658f745ed8a9fe65fb901e624ed2541a56",
    "fa94367a2ea010bf012eea6d09cbef48c610a963"
  ],
  "author": {
    "name": "Jonathan Brouwer",
    "email": "jonathantbrouwer@gmail.com",
    "time": "Tue Mar 03 07:14:12 2026 +0100"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Tue Mar 03 07:14:12 2026 +0100"
  },
  "message": "Rollup merge of #153227 - kpreid:struct-missing-field, r\u003destebank\n\nDon’t report missing fields in struct exprs with syntax errors.\n\n@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u\u003dkpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.\n\nSpecifically, if the user writes a struct literal with a syntax error, such as\n\n```rust\nStructName { foo: 1 bar: 2 }\n```\n\nthe compiler will no longer report that the field `bar` is missing in addition to the syntax error.\n\nThis is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.\n\n**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.\n",
  "tree_diff": []
}