Christmas request! VD closure debugging

[Michelle Long]

>> [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.
>

By globals I mean anything global to the current scope. I don't 
know if there is already a name for these variables.

> 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.

Yeah. Maybe a better approach or another approach is to provide a 
single "global access" that allows one to see any variable at any 
point in time that is available to the compiler by digging down a 
tree. Lua sorta has this with _G.

The idea is that if something is not being show or accessed one 
can go find it if necessary, that way there always is some way to 
see a variable.

It would simply have to deal displaying the information 
correctly(threading, availability, etc).

> 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.

ok.

>
>> 
>> 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?

That would be something I wouldn't know about. The compiler 
thinks case statements shadow variables so it doesn't seem to be 
aware or treat case statements as their own scope.

If the debugger can determine it is in a switch statement and get 
the line info of the cases then it could brute force it but this 
sounds like to much work for something that probably could be 
done in a few lines of code.