• Ben Jones (24/24) Aug 22 In my dconf talk I mentioned an idea for helping to debug
• Denis Feklushkin (4/7) Aug 22 I think just finishing compilation would be the best idea
• Steven Schveighoffer (3/10) Aug 22 You wouldn't put this in unless you are working interactively.
• Denis Feklushkin (3/3) Aug 22 On Friday, 22 August 2025 at 09:11:55 UTC, Ben Jones wrote:
• Monkyyy (11/36) Aug 22 Upstream is terrified of the concept of exposing th order of

Ben Jones <fake fake.fake> writes:

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?

Denis Feklushkin <feklushkin.denis gmail.com> writes:

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

 Ideally (eventually) pragma(breakpoint) would pause the 
 compiler and provide analogues to normal debugger functions 
 such as examining values

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

Steven Schveighoffer <schveiguy gmail.com> writes:

On Friday, 22 August 2025 at 13:10:18 UTC, Denis Feklushkin wrote:
 On Friday, 22 August 2025 at 09:11:55 UTC, Ben Jones wrote:

 Ideally (eventually) pragma(breakpoint) would pause the 
 compiler and provide analogues to normal debugger functions 
 such as examining values

 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

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

-Steve

Denis Feklushkin <feklushkin.denis gmail.com> writes:

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

Monkyyy <crazymonkyyy gmail.com> writes:

On Friday, 22 August 2025 at 09:11:55 UTC, Ben Jones wrote:
 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?

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.