Christmas request! VD closure debugging

[Petar]

On Friday, 14 December 2018 at 03:21:58 UTC, Michelle Long wrote:
> I've mentioned this before but I am really struggling with this 
> issue and it is probably the biggest problem I have with VD + D 
> in general.
>
> Again, any nesting of stuff (such as functions) or opApply 
> overrides of foreach and other cases lose scope of the locals 
> above it(it's globals) are lost in the locals, auto, watch, 
> etc....
>
> This makes it tremendously difficult to debug unless hard 
> aliases are created... which uglify the code and must be 
> maintained to prevent having to constantly re-add them and 
> remove them.
>
>
> You told me that dmd and walter do not think it is a big issue 
> and that it is a problem with dmd. If this is true surely you 
> can use your clout to get him to change his mind. He doens't 
> realize the headache this causes in debugging. The whole point 
> of being able to see the contents of variables is at the 
> essence of debugging. Without it the debugging experience would 
> be rather pointless.
>
> I'm not sure what is required and how it can be done much less 
> of the exact cause so I implore you to try to convince Walter 
> it is necessary for VD to function properly. Surely some 
> compromise could be had. D is a very nested language and many 
> times a simple nesting of a function and or struct can make all 
> the difference in a problem.
>
> But even since opApply exhibits this problem, it is very 
> common. I run across it even when I am using library code or 
> anything that overrides foreach. I actually though I remembered 
> not having this problem a while back or I'm sure I would have 
> complained about it from the get go... but I could be wrong or 
> just not experienced it much at the time.
>
> I don't think it would be a hard problem to solve since it 
> really is just keeping track of the variables addresses and 
> which ones that need to be exposed. But maybe this is not so 
> easy to get working?

Have you had the chance to compare the debug information that LDC 
produces with that of DMD? Since LDC follows relatively closely 
dmd, it shouldn't be too much work to switch between the 
compilers back and forth. My understanding is that since it uses 
a different API internally (that of LLVM) its output can 
different and better than that of dmd. Also it can benefit from 
improvements that the broader LLVM community provides, 
independently of the LDC/DMD devs.

Walter himself is not against debug experience improvements (just 
the contrary), it's just more likely that he doesn't use a 
source-level debugger himself and has higher priority issues on 
his list. But as someone who participates (when I have a little 
free time) in the development, I can assure you that he's not 
against any well documented and implemented improvement.
I myself like meta programming, and the complete lack of 
debugging has taught me to write my code in more easily unit 
testable manner. I don't know your codebase, so I can't make any 
informed recommendations, but I have often found that splitting 
complex code in smaller more general building blocks helps me a 
lot.
Of course, having used C#'s excellent debugger for all kinds of 
code with async/await, LINQ, nested lambdas, etc. I know how much 
D debuggers can improve.

You can have look at the debug info tests here: 
https://github.com/ldc-developers/ldc/tree/master/tests/debuginfo 
to get a sense of the level of support. Often, if you follow a 
commit that made a change to those files, you would find 
insightful discussions in the pull request that introduced them.