Debugging mixins - we need to do something

[Nicholas Wilson]

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.