Christmas request! VD closure debugging

[Rainer Schuetze]

On 18/12/2018 21:09, Michelle Long wrote:
> Ok, I installed the latest dmd,rebuilt some libraries and the source for
> it then tried some code I had and the parent variables did not show up:
> 
> The code was effectively
> 
> auto foo()
> {
>     int x = 0;
>     auto bar()
>     {
>        int y = 0;
>        x++;
>     }
> }
> 
> I put a BP on the `int y = 0;` line and the variable x is not being
> displayed.
> 
> x is not showing up in the locals but I did add it as a watch and it
> seemed to show it just fine. This might just be a simple display bug for
> locals. It is also showing up for autos! So this is actually good and
> seems to be working. I was mistakenly thinking they should be locals.

That's a bug in the mago extension that hides the captured variables if
they are from a stack capture, not an allocated closure. Fixed in the
next version.

BTW: if you enable showing internal symbols in the mago options, you can
see __capture as the actual local with the captured variables as its
struct fields.

> 
> I tend to use only locals rather than auto's and watches because of the
> screen real estate required.
> 
> Not sure if there is any feasible solution.


> 
> Would it be possible to have, say, a variable in the locals called
> "globals"(or some better name) that contained all the globals to the
> scope or just list the globals inline(like autos does) when there are
> just a few or when they are just one level above(which would get most
> needed cases)? Possibly prefix the variable with something like @ or #
> to signify it is a global in this case.
> 
> Again, the main idea is to save screen space and time by not having to
> juggle windows. Locals tend to cover most cases fine(biggest problem I
> have with it is that I tend to have trouble finding a specific variable
> by name since the list is in some order that makes no sense to me...
> definitely not alphabetical and VS doesn't allow sorting... I'd actually
> preferred them sorted, or at least have it as an option since then I can
> locate the variables much quicker).
> 
> 
> Possible solutions:
> 
> 1. + Globals
>        x
>        ...
>    y
> [Just list all global variables to the current scope in a globals tree]
> 
> 2. y
>    + Globals
>         x
>         Globals
>         ...
> [Show the globals in a tree if that info is available]
> 
> 3. x
>    y
> [If there are just a few globals or parent variables then inline them]
> 
> 4. 1 at x
>    y
> [using prefix, 1 is the ancestor level of the variable and @ is just
> stating it is global]

Globals are a bit problematic because there is no debug information
about what's currently imported, so name lookup can be ambiguous (and
using the language service will likely be too slow). There is some
support to figure the current scope of a function if it is extern(D), so
that statics and globals in the same module can be resolved.

I wouldn't want to add globals to the locals window as it could slow it
down, but having some special symbol to explore them in a tree (built
from fully qualified names) in the watch window might be a feasible
solution.

> 
> 
> 
> 
> Optional's:
> 1. Allow different sorting of variable names in the locals, autos,
> watches, etc. Not sure why VS doesn't have this built in, maybe a switch
> is required or something must be setup? Most programs that display any
> type of information in a column will allow it to be sorted. I think that
> VS does do this in C# but I can't recall.

Sorting the list by clicking on the column header is not under control
of the extension, but for locals an option could be added. These are
listed as they are found in the debug information.

> 
> 2. case scopes seem to capture(show in locals) all the variables outside
> it. That is, a case doesn't seem to create it's own local scope.
> 
> case 1:
>    int x;
> case 2:
>    int y;
> 
> x is shown while debugging in y... x is not needed to be seen though.

The compiler will have to generate proper scope information. Maybe this
already works if there are conflicting declarations as with other scopes?

> 3. List types from derived to base instead of base to derived(already
> discussed before).
> 
> 
> You can do all this stuff when ever you feel like it of course... Just
> pointing out some improvements. I haven't tested the globals fix yet but
> if it works well then I will just switch to autos or use a watch when I
> need to.
> 
> 
> 
> 
>