GSoC Retrospective

This will be a more informal brain-dump of my thoughts on how my GSoC project went. This was written around the same time as the more formal Final Report (i.e. before I've recieved my final evaluation), but I did wait to do a final pass and proofread until after the final evaluation. During the mentor's evaluation period, I took the first real break I've taken since around March or April, mostly so I could look at literally any other code at all. I've been tinkering with an RTS engine I've had on the backburner for a long time, as well as a very silly Python project that I'll probably make a post about soon.

In any case, I'm pleased to say that I passed my final evaluation! I have some additional awesome news. Just before my project ended, I recieved a surprise DM notifying me that a few people had nominated me for Rust Compiler Team membership! I accepted, and I'm very excited to keep contributing to Rust for the foreseeable future. It maybe sounds silly, but as someone who hasn't like... done a whole lot with their life, or had a whole lot of opportunities, seeing my name on the official website alongside the names of people whose blogs I've been reading for years made me tear up a little.

2026-10-05 · 16 min · 3042 words

GSoC 2026 Final Report

2026-09-20 · 7 min · 1273 words

GSoC Debuginfo Test Rework: Data

As I mentioned in my previous post, I started a Google Summer of Code project to (more or less) dig tests/debuginfo out of tech debt.

The original plan was to create and entirely new test suite. Tests would slowly be translated over, and then the old test suite would be removed. There was a bit more complexity with this option, between the plumbing for the new test suite, and the coordination between the two. There was also the matter of preserving the behavior of the tests that do more than just print variables (e.g. stepping behavior in macros).

2026-05-30 · 16 min · 3028 words

Rust Debugging Progress Report May 2026

Since my last post, my work regarding Rust debugging as slowed a bit. The fixes to the visualizers assuaged my annoyance enough to finish some side projects. Crafting Interpreters, and a rewrite-it-in-rust of a python tool that turns Kindle Scribe notebook files into SVGs, and some other silly stuff. The break was a fat reminder of how weak the debugging experience still is, and it has worked wonders to refresh my spite-based motivation. Before I hang my "It doesn't have to be this way. We make our own tools." poster back up, I want to do a bit of a brain dump.

2026-05-11 · 13 min · 2518 words

LLDB's TypeSystems Part 2: PDB

In my previous post, I described implementing PDB parsing as a can of worms. That might have been a bit of an understatement. PDB has been one "oh, it's gonna be twice as much work as I thought" after another. Implementing it has revealed many of the same issues as the TypeSystem itself: lack of documentation, cryptic implementations, poor naming schemes, and unclear expectations. Despite all that, I was able to get it working.

That means TypeSystemRust can be used for executables that target *-gnu or *-msvc. It's not quite done yet, but this is a massive step towards the TypeSystem being fully complete. I want to talk a bit about the process, at least partially for posterity. As we'll see later, PDB itself is also not documented very well, so any additional literature could be helpful to someone down the line.

Fair warning, we're getting into the weeds. This is gonna be a long one.

2025-07-07 · 37 min · 7386 words

LLDB's TypeSystems: An Unfinished Interface

Well, it's "done". TypeSystemRust has a (semi) working prototype for LLDB 19.x. It doesn't support expressions or MSVC targets (i.e. PDB debug info), and there are a whole host of catastrophic crashes, but it more or less proves what it needs to: Rust's debugging experience can be improved, and there are worthwhile benefits to a working TypeSystem that can't be emulated on other layers of the debugging stack.

If you want to test it out, you'll need to build my fork from source (sorry), but then lldb.exe can be used as-is, or you can point a debugger extension like lldb-dap or CodeLLDB to your newly built lldb-dap.exe or liblldb.dll respectively. If you're on Windows, make sure to compile for MSVC otherwise CodeLLDB won't be able to interface with liblldb properly.

2025-03-28 · 25 min · 4884 words

So you want better debug info?

Let me start with an emphatic "me too".

I've put many of my side projects on hold because recent events have resulted in, what I consider to be, an unacceptable degredation of the debugging experience. It's a bit hard to focus on whatever I'm doing when I have to fight to figure out what's in a Vec. One of the great things about programming is that we're the ones who make our own tools; we don't have to just blindly accept mediocrity.

2025-02-14 · 25 min · 4926 words