Rust compiler team adds Anthony Bolden for debugger work

On 2 November 2026, the Inside Rust blog published a maintainer spotlight on Anthony Bolden (@Walnut356). He is a self-taught contributor who joined the Rust compiler team after a Google Summer of Code project on debuginfo tests. If you debug Rust with LLDB, GDB or CodeLLDB, and especially if you build for Windows MSVC, the visualizers you use are being actively maintained, and you can help by reporting broken output.

What the spotlight reports

Jakub Beránek wrote the post for the Rust Content team. It is part of a series about people who maintain the toolchain, "often on a volunteer basis on top of another job". The previous post in the series, from 21 September 2026, profiled Alejandra González. Bolden's Rust team page now lists him as a member of the compiler team and as a GSoC mentee.

The facts that matter for developers:

• His first contribution went into the toolchain itself. Bolden writes: "Back in 2024, the Rust toolchain did not distribute debuginfo visualizers on Windows." He fixed that in PR #133737, titled "Include LLDB and GDB visualizers in MSVC distribution". The PR says MSVC and LLDB/GDB are often used together, for example in VS Code with CodeLLDB or lldb-dap.
• Tests replaced screenshots. At the time, the compiler's debuginfo test suite "did not work on Windows at all", so he showed that his pull requests worked by posting screenshots. His 2026 GSoC project was about improving those debuginfo tests.
• Why he started. CodeLLDB dropped its built-in Rust support and fell back to the scripts that ship with the Rust toolchain. Those scripts were not part of MSVC toolchains. He tried to fix the problem in LLVM first. When that failed, he cloned the Rust repository, and the build "just worked" on the first try.
• What comes next. Now that "the debuginfo testing situation is no longer so dire", he wants better visualizers for Vec and wide pointers, a way to index hashmaps in the debugger, and speed improvements. He also mentions some longer-term ideas. LLDB's maintainers plan to improve LLDB's plugin interface, which could allow a native Rust integration. Other ideas are visualizers written in Rust and integration with Miri.

The post also says his night-auditor job at a hotel was eliminated and that he is now looking for software engineering work. He would like to work on Rust debuginfo full time.

Who is affected and why it matters

The work fits the Rust Project's own data. The Rust debugging survey 2026 results came from more than 2,300 responses. Slightly over 74% of respondents reported poor representation of values as a pain point, and just over 55% said they could not print variables. Respondents named enums, HashMap and Vec as hard to inspect. On Windows, WSL and macOS, lldb inside an IDE was the most common debugger setup.

The spotlight also shows how the Project grows maintainers. A volunteer fixed a tool he used, did a GSoC project, and was then invited to the compiler team. For more on how the Project is trying to pay people doing this kind of work, see our report on the Rust funding guide and the Maintainer in Residence model.

What to do now

The survey found that nearly 62% of library authors did not know about the debugger_visualizer attribute. If you maintain a crate with types that look unreadable in a debugger, you can ship visualizers with the crate. This example comes from the Rust Reference:

#![debugger_visualizer(natvis_file = "Example.natvis")]
#![debugger_visualizer(gdb_script_file = "example.py")]

The attribute can only go on a module or the crate root, and you can use it more than once. GDB does not auto-load embedded pretty printers. The Reference gives this launch form to allow them:

gdb -iex "add-auto-load-safe-path safe-path path/to/binary" path/to/binary

Steps for application and library developers:

1. If you use LLDB or CodeLLDB with an MSVC toolchain, update to a current stable toolchain so you get the bundled visualizer scripts and later fixes.
2. If a standard library type such as an enum, String, Vec or HashMap shows internal fields instead of its contents, write down your debugger, its version and your target triple, and report it on the rust-lang/rust issue tracker.
3. If you maintain a crate, add a Natvis file for -windows-msvc users and a GDB pretty printer for everyone else, using the attribute above.
4. If you want to work on debuginfo yourself, read Bolden's blog (linked from the spotlight) and the GSoC debuginfo test project linked from the survey results post.
5. To support maintainers directly, the spotlight points to the Rust Foundation Maintainers Fund on GitHub Sponsors.

Caveats

The spotlight is a profile, not a release announcement, and it does not say when Bolden joined the team. The improved Vec, wide pointer and HashMap visualizers, a native LLDB integration and Rust-written visualizers are plans or ideas with no dates. Bolden describes the current scripts as working "reasonably well" for LLDB on Windows, not perfectly.