Good time of day, everyone

Recently I've got myself into D Language again, but got a problem with debugging on Windows, obviously. While Visual D with Mago provides pretty comfortable workflow, I highly appreciate what Code D did with it's more closer and tight integrating with DScanner and DFormat, better DUB workflow and so on... The biggest problem there is debugging on Windows OS. GDB from either Microsoft's C/C++ plugin (ms-vscode.cpptools) or WebFreak's Native Debug (webfreak.debug) didn't took me anywhere. Broken Mago-MI integration in WebFreak's Native Debug (which I have "fixed" locally after few moves around) didn't took me far as well, the best I got was something bad about Stack Frame.

Meanwhile, the original Microsoft's Visual C++ Debugger (cppvsdbg) is working pretty much flawless with D. With the problem, of course, not being able to show what is inside of the slice/dynamic arrays. Having "fun" with Natvis (The Visual Studio Natvis framework lets you customize the way Visual Studio displays native types in debugger variable windows) I found that giving D types to catch won't work as Visual C++ Debugger (cppvsdbg) is expecting valid C++ names to work with.

I mostly gave up there, but then I found interesting trick that Visual Rust and Rust plugin for Visual Studio Code are using. They added option to compiler to write debug information as that's C++ code (so they doesn't have to come up with their own debugger for Windows), with pretty simple trick in rustc and simplest Natvis file they then have integrated into PDB that they ship with it. So I've tried to apply that to DMD and see what will happen.

Currently, as matter of experiment, I've changed it on my side permanently, but thinking about adding new flag to DMD. The change was about this big:
// --------------------------------
diff --git a/src/dmd/hdrgen.d b/src/dmd/hdrgen.d
index d9eca8721..a02c6bfef 100644
--- a/src/dmd/hdrgen.d
+++ b/src/dmd/hdrgen.d
@@ -814,8 +814,9 @@ public:
         else
         {
         L1:
+            buf.writestring("__dlang::__darray<");
             visitWithMask(t.next, t.mod);
-            buf.writestring("[]");
+            buf.writestring(">");
         }
     }
// --------------------------------

Now, equipped with that one and fairly small Natvis file that can be integrated into DMD somewhere and/or Code D, I've got nice views with flawlessly working Visual C++ Debugger on my D code. For matter of showcase, links with the screenshots:

1) https://cdn.discordapp.com/attachments/463259852311887874/491953617545330689/unknown.png
2) https://cdn.discordapp.com/attachments/463259852311887874/491956446469029888/unknown.png

This one can be further expanded with correct expanding of string, wstring, dstring and/or any other built-in interesting/specific/complex types from D. What people working on DMD think about adding something likes this? Will it break everything? What if that will be added as DMD command line option to make life easier for end user on Windows for their own projects (at least they may enable that temporary while debugging, so it won't add side effects to anything else)?

P.S. Even without any optional switch that haven't broke Mago on Visual D, so working with D, especially debugging, can become far, far easier than it's now. Even with this small change I'm able to continue working on my project without thinking twice why I haven't stayed on C++.

On Wednesday, 19 September 2018 at 14:22:13 UTC, Void-995 wrote:
> [...]

Cool!

> What if that will be added as DMD command line option

DMD used to have the switch -gc, which meant to emit debug information but pretend to be C as much as possible. It was removed as it wasn't considered necessary any more, but this looks like the perfect use case for it.

I suppose it's not possible to make Natvis understand D symbols?

Rainer Schuetze would be the person closest to this topic, I think. Doesn't Visual D already have something in it to get the VS debugger to understand some D types better?

On Wednesday, 19 September 2018 at 14:29:27 UTC, Vladimir Panteleev wrote:
> On Wednesday, 19 September 2018 at 14:22:13 UTC, Void-995 wrote:
>> [...]
>
> Cool!
>
>> What if that will be added as DMD command line option
>
> DMD used to have the switch -gc, which meant to emit debug information but pretend to be C as much as possible. It was removed as it wasn't considered necessary any more, but this looks like the perfect use case for it.
>
> I suppose it's not possible to make Natvis understand D symbols?
>
> Rainer Schuetze would be the person closest to this topic, I think. Doesn't Visual D already have something in it to get the VS debugger to understand some D types better?

Unfortunately you can't make Natvis to understand D symbols as it's purely for C++. You can make C# extension for Visual Studio to do pretty much whatever, but that's not usable much as it doesn't work for VS Code from what I found (and C# are extremely complex for this matter from my point of view). I think Visual D is using Mago internally via DLLs or something, and doing it's own thing.

Something like -gc would be great to have again (I guess I missed that one), even -gcpp (to pretend it's C++) that can be used by pretty printing in GDB (fairly simple changes in Python scripts from printing standard C++ stuff) and Microsoft's Debugger. So the classes, namespaces, containers, dynamic arrays can be easily represented with actually having structure and sense from C++ point of view.

On Wednesday, 19 September 2018 at 14:37:32 UTC, Void-995 wrote:
> On Wednesday, 19 September 2018 at 14:29:27 UTC, Vladimir Panteleev wrote:
>> [...]
>
> Unfortunately you can't make Natvis to understand D symbols as it's purely for C++. You can make C# extension for Visual Studio to do pretty much whatever, but that's not usable much as it doesn't work for VS Code from what I found (and C# are extremely complex for this matter from my point of view). I think Visual D is using Mago internally via DLLs or something, and doing it's own thing.
>
> Something like -gc would be great to have again (I guess I missed that one), even -gcpp (to pretend it's C++) that can be used by pretty printing in GDB (fairly simple changes in Python scripts from printing standard C++ stuff) and Microsoft's Debugger. So the classes, namespaces, containers, dynamic arrays can be easily represented with actually having structure and sense from C++ point of view.

Forgot to mention that Microsoft added partial support (that may be more than sufficient for D case) to their C/C++ in VS code for both GDB and LLDB. So this one may be useful to make debugging more friendly on Linux and Mac as well!

On Wednesday, 19 September 2018 at 14:29:27 UTC, Vladimir Panteleev wrote:
> On Wednesday, 19 September 2018 at 14:22:13 UTC, Void-995 wrote:
>> [...]
>
> Cool!
>
>> What if that will be added as DMD command line option
>
> DMD used to have the switch -gc, which meant to emit debug information but pretend to be C as much as possible. It was removed as it wasn't considered necessary any more, but this looks like the perfect use case for it.
>
> I suppose it's not possible to make Natvis understand D symbols?
>
> Rainer Schuetze would be the person closest to this topic, I think. Doesn't Visual D already have something in it to get the VS debugger to understand some D types better?

Thanks for pointing me at -gc. That's way better place to continue needed work for making Natvis working properly and happy. Of course, the start is ugly, bat that's the start: https://www.dropbox.com/s/vb5fjwclrzcwl3l/dmd-return-of-gc-for-natvis-0001.diff?dl=0