VisualD's Proof Of Bigfoot!

[Rainer Schuetze via Digitalmars-d-ide]

On 21.07.2017 21:37, FoxyBrown wrote:
> Here is a visual to prove some of the bad behavior that visual D is 
> having and turning me off from D. Since no one will believe that such 
> problems could exist, I decided to get a video of the yeti up close and 
> personal.
> 
> The video should be self explanatory. These are not the only problems I 
> have run in to with Visual D. I do not think my system is unique, 
> windows 10 + Visual Studio 2017. Anyone that uses that combination 
> should run in to these issues fairly quickly I'd imagine(I've had them 
> on several other system combinations also).
> 
> I have issues with the watch values not being correct. They also are 
> reported before they "exist"(according to the line number. They should 
> be hidden if the local line number < declaration line number of the 
> variable).
> 
> http://s000.tinyupload.com/index.php?file_id=89572735278741121549

Thanks for taking the time to create the videos and report these issues. 
Most of these are not strictly Visual D problems, but caused by the 
compiler emitting incomplete or bad debug information. I concur that 
this doesn't really make a difference to a user, though.

1. bad line number info for if statements: I haven't yet seen something 
similar to your case (I suspect writing the full if/then/else block into 
a single line makes it worse). Instead, the debugger sometimes seems to 
execute the then-statement when actually skipping it.

2. no debug info for ssp: this looks like 
https://issues.dlang.org/show_bug.cgi?id=4014 which should be resolved 
in git-master of dmd (new option -gf).

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

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.

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.

6. compiler generated variables: the latest rc of Visual D (the mago 
debug engine to be precise) allows to hide these variables (see 
Tools->Options->Debugger->Mago).

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.

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

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.