Two visual D suggestions:

[Alex]

On Friday, 17 May 2019 at 07:48:00 UTC, Rainer Schuetze wrote:
>
>
> On 16/05/2019 11:19, Alex wrote:
>> Could Visual D just not internally add this for me? We know it 
>> has the info because I can do go to definition and it takes me 
>> to the right module, so it seems it could first check if it 
>> gets
>> 
>> D0013: Error: Symbol not found
>> 
>> and if so then auto-resolve the name by fully qualifying it 
>> and then trying again...
>> 
>> Should be pretty simple and a just a few lines of code, 
>> assuming the FQN is easy to get.
>
> Unfortunately, it is not. The semantic engine and the debugger 
> extension are unaware of each other. Even if they are, symbol 
> lookup might slow down the debugging experience quite a bit.

;/


> IIRC GDC emits symbol lookup information (e.g. imports) to the 
> debug info. I think this should happen with DMD or LDC, too.

Sure... whatever would be easiest to get things to work properly.

Surely the debugger can get the information. For this specific 
issue of adding a variable to the watch, it would only have to 
qualify it on adding the variable.

What I'd do, at least as a temporary work around is this:

When symbol cannot be resolved in the watch/autos/local:

Some how get the FQN. Either from the json files, or "ask" the 
semantic engine. [or ideally get dmd/ldc to give the info].

If speed is an issue, only do it when adding the name and cache 
it. This would be done once and so won't can't slow things down.

If multiple FQN's are found then require explicit casting.

It then seems the bulk of the work is getting the FQN. If that 
can be done relatively easy, even if a temporary hack, it might 
be worth it.


Remember, all one is trying to do is "cast(X)x;" and so it is 
just a matter of getting X for x... which is just something to 
"look up" somewhere.

If the semantic engine and debugger extension need to communicate 
with each other then maybe create some code to make a simple 
communications layer where information can be passed(could use 
json encoding).


Of course it might be much easier just to get the compilers to 
emit this information? Probably actually only a few lines of code?