)]}'
{
  "commit": "adcc5f3bdc1a3c205141996ba01404b6e4b27310",
  "tree": "c9d702431fc64929c06690f7d3b4dce9671ac9bd",
  "parents": [
    "9c99d05505bccb67912d68e05fe7fc7c58afcb41",
    "a411a33bded5f536f7e8e15e6789fe8b6a6ea6b8"
  ],
  "author": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Sat Sep 12 14:45:47 2026 +0000"
  },
  "committer": {
    "name": "bors",
    "email": "bors@rust-lang.org",
    "time": "Sat Sep 12 14:45:47 2026 +0000"
  },
  "message": "Auto merge of #160377 - Walnut356:gdb_di_repr, r\u003dKobzol,jieyouxu\n\nAdd `gdb-repr` directive for `tests/debuginfo`\n\n\n\nPart of https://github.com/rust-lang/rust/issues/148483 and followup to https://github.com/rust-lang/rust/pull/158298. Applies (approximately) identical logic to GDB.\r\n\r\nI still need to test things on `windows-gnu` (and locally try a few more tests to see if there\u0027s any glaring issues). There\u0027s also a few bike-sheddy things.\r\n\r\nThe main way this differs from the LLDB implementation is that GDB doesn\u0027t use `lldb_batchmode/runner.py` to orchestrate the commands. Instead, I have `compiletest` import `from_gdb.py` which registers a custom `repr` CLI command. GDB\u0027s batch processing works as normal, but dispatches to our logic automatically whenever it encounters `repr \u003cvar_name\u003e`.\r\n\r\nAn additional `repr-finalize` CLI command is also registered to implement the checks that ensure we encountered all expected types/vars, and verifies that there were no errors before saving blessed data.\r\n\r\nr? @Kobzol, @jieyouxu ",
  "tree_diff": []
}