Working Zig debugging in Zed

Showcase
, , ,
1

I’m learning Zig by hand-writing a HOCON parser, and all I wanted was to put a breakpoint into a test and look inside my ArrayList. That turned into three fixes for the Zed zig extension, one one-line patch for the Zig compiler, and a write-up.

All of this started as my own pain. I fixed it locally first, I’ve been running on this setup daily since, and this post is really just me sharing it onward.

The interesting parts were not the bugs themselves but the decisions behind the fixes:

  • Where to emit the test binary. The extension generated zig_test_<uuid> into the project root on every debug run, and nothing ever deleted them (there is no post-session hook in the extension API). I went with a single fixed .zig_test name relative to the task cwd that just overwrites itself. .zig-cache/ would be nicer, but zig refuses to create a missing output directory, so it would break on fresh checkouts.
  • How to load the LLDB pretty printers safely. Zig ships formatters for slices/ArrayList/optionals (lib/lldb/pretty_printers.py since 0.17, tools/ before that), but nothing loads them. The trap: a failing initCommands entry aborts the whole CodeLLDB launch. So the extension routes the import through script + HandleCommand, which only prints the error — a missing script can never take down your session.
  • Type names in the Variables panel. Zed currently drops the DAP type field, so the summaries put the type in the value: parts = std.ArrayList(Ast.Node) len=3 capacity=4. A small marked section on top of the upstream script. This made me feel like in JetBrains.
  • The compiler part. Locals initialized with try vanish from debuggers one step later — a DW_TAG_lexical_block with ~24 bytes of address range. Root cause was a defer dropped in an October refactor; fix in ziglang/zig#36415 (reviewed, waiting for merge), regression tracked in #30705.

Extension PRs: zed-extensions/zig#44 #45,#46. Until they land, everything is on the all-fixes branch of my fork extension.

AI / LLM usage disclosure

I used Claude Code heavily as a debugging partner: the dwarfdump archaeology, DAP-level testing of CodeLLDB behaviour, and drafting the extension patches — which I reviewed, tested, and take responsibility started all this is typed by hand, that’s the whole pointof learning. The article was edited with AI as well.

Debugging Zig (with a debugger)