)]}'
{
  "commit": "ab5beacfd3914a70e57acafde6a74b590fbaf1b2",
  "tree": "a72d6dc2a7ee748786661bfa880a89d59cc4e789",
  "parents": [
    "942ac9ce4116d4ea784c9882659372b34978b1f8",
    "f835c9651042112e6135615e971b1639bbcc700c"
  ],
  "author": {
    "name": "Jacob Pratt",
    "email": "jacob@jhpratt.dev",
    "time": "Mon Jun 22 03:07:49 2026 -0400"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Mon Jun 22 03:07:49 2026 -0400"
  },
  "message": "Rollup merge of #157529 - Walnut356:serde, r\u003djieyouxu,kobzol\n\nAdd `tests/debuginfo` data classes to define schema\n\nPart of https://github.com/rust-lang/rust/issues/148483\n\nThis is part 1 of 3(?) of upstreaming the new testing infrastructure, after which we can start converting the existing tests and/or replacing old tests with new, better written tests. This patch includes the test data format (in the form of several `@dataclass` classes), as well as serialization/deserialization. `common.py` includes a LOT of comments regarding what information is stored and why we store it. If anything is missing or unclear, please let me know. Some information about GDB that I knew off the top of my head I filled in, the rest will be filled in once GDB support is added.\n\nThe next patches will include the `compiletest` plumbing, comparison logic, and error handling.\n\n---\n\nSerialization to JSON is as simple as using the builtin `json.dumps` with `dataclasses.asdict(test_data)`. Deserializing the JSON data is taken care of by `from_dict`, which uses the type annotations (which exist and can be manipulated at runtime 🤢), to detect when a `dict` is actually a dataclass, and then dispatches it to the dataclass\u0027s constructor. It\u0027s kinda magic, but I hopefully left enough comments that it should make sense. Doing it this way means we never really have to touch this function again, it should Just Work™ even if we adjust the dataclasses themselves.\n\nConverting from LLDB is very straightforward. The only difference between this and my mock-up is how types are handled. Before, I stored full type data for the variable and for the type\u0027s field\u0027s types (recursively). This lead to a lot of redundant information. Since any given type\u0027s data is unique and unchanging for a given target in a given session (as guaranteed by LLDB), we can store exactly 1 instance of each `Type`. Variables and children store their type as a `str`, which can be looked up in `TargetData.types` to test against the appropriate type data. This assumes that type names can\u0027t collide, which isn\u0027t *entirely* true, but the only instances I\u0027ve encountered are either LLDB bugs or resulted in LLDB itself crashing anyway, so it should be fine for a highly constrained testing environment like this.\n\nStatic fields are currently not handled. As discussed on zulip, we\u0027re targeting `x86_64-unknown-linux-gnu` first. The only static fields that Rust outputs are for sum-type enums on msvc targets. Static fields can only be accessed by name (nearly everything else we access we can get an item count and look up by index in a loop). I\u0027m considering my options for how I want to handle those. Realistically, it\u0027s not super urgent and can be slotted in at any time (and might serve as a good test later down the road of updating existing test data to a new schema).\n\nr? @jieyouxu, @Kobzol\n",
  "tree_diff": []
}