VisualD's Proof Of Bigfoot!

Rainer Schuetze via Digitalmars-d-ide digitalmars-d-ide at puremagic.com
Sun Jul 23 00:56:14 PDT 2017



On 22.07.2017 20:36, FoxyBrown wrote:
> On Saturday, 22 July 2017 at 08:20:00 UTC, Rainer Schuetze wrote:
>>
>> 3. globals have to specified with their fully qualified names in the 
>> watch window because the compiler does not emit symbol lookup 
>> information (e.g. imports).
> 
> Surely we could ask for an enhancement to do this? 

AFAICT GDC has implemented this to some extend. It would be nice if the 
that information would be available: 
https://issues.dlang.org/show_bug.cgi?id=17675


> The problem is, any 
> lower scope seems to also have these issues. >
> I'm not sure if I made a video of it, I think it did, but if I put a BP 
> on an inner block and run to it, then the outer blocks variables are not 
> shown. If I step in to that inner block then they are shown. It's as if 
> the debugger doesn't bother or can't collect the variables outside of 
> the scope when not stepped through. This could be a similar issue with 
> the globals, being the outer most scope, might just be ignored.

As noted below, this is likely caused by nested functions, either 
explicitly or implicitly added by the compiler.

> 
> 
>> 4. Intellisense: D is a quite complex language, which makes it not so 
>> easy to provide good intellisense information (using the compiler as a 
>> library is work in progress, but is unlikely to be usable in the near 
>> future). Especially if inference (e.g. with "auto") is involved, it 
>> can get pretty difficult.
> 
> Surely the compiler can emit the type to use? It has to know it. Maybe 
> the compiler could be modified to output D debug info that you could use 
> for mago to enhance it?

Intellisense must work while you type, so there is no debug information 
available at that time. Very likely the current text isn't even compilable.

> 
> Should be relatively easy to do? I think the main problem
> 
>> 5. foreach loops: with ranges, the compiler usually translates the 
>> loop body into a delegate, which it calls during iteration. With 
>> incomplete context information, this hides local variables of the 
>> outer functions. See the call stack when stepping through the loop body.
> 
> Ok, maybe that was what I was talking about in 3. Again, surely the 
> compiler can emit information to help with this? The compiler and mago 
> should be coupled in such a way that mago can function properly.

Yes, the compiler could help: https://issues.dlang.org/show_bug.cgi?id=4898

> 
>> 7. some jump instructions are elided by the compiler even in debug 
>> builds, which causes the bad behavior with "continue". I tried 
>> disabling that optimization but Walter was against it. Maybe this 
>> should be restricted to jumps with no or identical debug line 
>> information.
> 
> Again, surely the compiler can emit information to help with this? a 
> -mago switch that outputs whatever info is needed by the compiler.

Sure, it just shouldn't remove that information.

> 
>> 8. "go to definition on an alias": not sure about this one: do you 
>> mean "Search Symbols"? This uses compiler generated information in 
>> JSON files. For phobos symbols you might want to run "Build phobos 
>> browse info".
> 
> When I use "go to" on a symbol that is an alias, it takes me to the 
> alias definition, but from there, I can't proceed because a go to on the 
> alias symbols leads no where. Hence, I have to do a search for the 
> symbol to find the actual reference.
> 
> I can make a video of it if your still confused. But basically trying to 
> "go to" any symbol that is backed by an alias(specially some win32 stuff 
> that aliases a lot of the unicode and ansi functions) should show the 
> problem.

I tried it on LoadLibrary, that took me to the alias to LoadLibraryA, 
which didn't let me go further. This is disabled code, though, it should 
have been LoadLibraryW. Go to definition on the respective alias 
definition works. Other alias definition in the vicinity of LoadLibraryA 
seem to work, though.

Is this what you are referring to?

> 
>> 9. enum values: very old bug: 
>> https://issues.dlang.org/show_bug.cgi?id=982. Not sure why it has been 
>> assigned to D1, only.
> 
> Ok. Can it show both the value and the symbol?  That will make it real 
> helpful ;)

If the information, that's up for the debugger to decide.

> 
> 
> My main issues is that it is simply difficult to program in D using 
> VisualD/Visual Studio. If my problems are not isolated, I think that 
> many C++/C# Visual Studio users will be turned off by D too.  While some 
> of the more advanced features are nice, the basic ones are the ones that 
> are relied upon and used the most and should just work. Not being able 
> to visualize a struct, for example, is a big problem IMO. It's something 
> I am so used to that I now rely on it as part of the debugging process. 
> IMO, the more info I can get at my fingertips, the better the 
> experience. When I have to fight the "debugger"(or whatever it is 
> ultimately) to do a job, it makes it difficult to enjoy what I'm doing. 
> I'd imagine it is more or less the same with everyone. Hopefully we can 
> get D/VisualD/VisualStudio up to snuff relatively soon so I can live 
> with peace and happiness ;)
> 

Unfortunately, Visual D is still a one man project, and I have also 
"inherited" maintenance of the external dependencies (the debug engine 
and the semantic engine). There is little help from the main D 
developers to improve debug information as they don't seem to use 
debuggers, but prefer printf debugging (which is sometimes better if a 
lot of information needs to be logged).

So it's pretty tough to meet the expected standards of C++ or even C# 
environments. Any help is welcome.


More information about the Digitalmars-d-ide mailing list