On Saturday, 8 September 2018 at 22:01:23 UTC, Manu wrote:
TL;DR, debugging is critical and neglected. Mixin is worst
offender.
So, string mixin breaks the debugger. All of a sudden there is
code that's executing that doesn't exist anywhere. We need a
solution to this problem...
As I and others have suggested before; mixin expansion should
emit a `[sourcefile].d.mixin` file to the object directory,
this file should accumulate mixin instantiations, and perhaps
it would be ideal to also emit surrounding code for context.
The debuginfo should point into that file when compiling mixin
code, so that it's possible to step and inspect within the
mixin.
How is this done in C/C++ w.r.t macros? Point to within the macro?
I initially imagined an 'expanded' copy of the file would be
cool, but that doesn't work when mixins are driven by template
args, since the expansion may be different for every
instantiation of the surrounding code.
There has been lots of chatter in the past, can we prioritise
it? It would help me a lot.
I think this is a high-importance ticket. I have absolutely no
idea
where to start with this, and I don't have anywhere near enough
time
to put towards my current initiatives (extern(C++) stuff).
Is anyone interested in this issue?
Obligatory "Bugzilla issue?". I don't think is should be too
difficult to come up with a really dumb solution, just dump
CompileStatement's string to a file, set the Lexer's loc to that
file and let regular debug info generation do its thing. I'm busy
for the next few days, but I'll take a crack at it if no-one
beats me to it.
