In my dconf talk I mentioned an idea for helping to debug template metaprogramming issues and took a first pass at implementing my idea here: https://github.com/dlang/dmd/pull/21758

The insight I had is that when I debug TMP code, I spray my code with pragma(msg) and am doing basically printf debugging. What would a "real" debugger for metaprograms look like?

I've implemented the first pieces that I think would be in such a tool:

• a way to specify breakpoints (pragma(breakpoint)
• a way to print a "backtrace"

In my implementation those two are intertwined and pragma(breakpoint) just prints the "backtrace" at that point in semantic analysis which is computed by tracing the scopes.

Ideally (eventually) pragma(breakpoint) would pause the compiler and provide analogues to normal debugger functions such as examining values (I think this would be the ability to info about various AST nodes), and once you're done inspecting the state of the compiler, you can "continue" to keep compiling.

Something that fell out naturally in the implementation is that you can make the breakpoints conditional by putting them in a static if block.

Does this seem like a useful addition? What's missing from my outline and/or implementation. How do people think they might use a tool like this?

On Friday, 22 August 2025 at 09:11:55 UTC, Ben Jones wrote:

I think just finishing compilation would be the best idea

In fact, we don't expect such infinity awaiting of user input from the compiler. Thousands scripts will be broken by this

On Friday, 22 August 2025 at 09:11:55 UTC, Ben Jones wrote:

Or maybe it should be disabled by default and enabled by CLI switch

On Friday, 22 August 2025 at 13:10:18 UTC, Denis Feklushkin wrote:

You wouldn't put this in unless you are working interactively.

-Steve

On Friday, 22 August 2025 at 09:11:55 UTC, Ben Jones wrote:

Upstream is terrified of the concept of exposing th order of compilation believing it's something that could change and maybe one day they will update the compiler away from the current model. (I find this notion laughable)

Compile values are all "bugs" if they change, but such bugs exist all over the place, it's only useful to keep track of the ones that don't step on valid syntax and don't crash.

If you a) got comfortable with the bugs and b) used them is a sensible way, you could implement CT values that mutate and you can grab snap shots of when you want.