On Wednesday, 26 September 2018 at 18:48:27 UTC, Void-995 wrote:
On Wednesday, 26 September 2018 at 18:06:48 UTC, Rainer
Schuetze wrote:
On 26/09/2018 09:45, Void-995 wrote:
On Wednesday, 26 September 2018 at 07:37:26 UTC, Rainer
Schuetze wrote:
[...]
Makes sense. I've tried to move them to "member" but they
obviously did not point anywhere, which is logical if that is
just "typedef". Is there any way to expose real key/values
from backend or get them via some Natvis magic? That's
basically only thing that stops from using MS C/C++ plug-in
for debugging from VS Code. Natvis support may be valuable
for Linux and Mac as well, as they've added minimal support
for Natvis to GDB and LLDB via their plug-in.
Not sure if you can define new structs in NatVis, but the void
pointer points to rt.aaA.Impl which contains an array of
Buckets, and their entry member points to a
std::pair<__key_t,__val_t>.
Thanks, I did something like that meanwhile:
https://www.dropbox.com/s/h70m4v63jxp79g1/d.natvis?dl=0
Need to take a look at other ideas as well. Of course it won't
hurt to clean that up, but this one works.
My C++ naming for NatVis experiment has been failed right now.
Somewhere around memory allocations which are all that kind of
spaghetti right now in backend of DMD. But! For x86_mscoff and
x86_64 associative arrays are named just as `dAssocArray`, while
slices are using full/real name from D. It's pretty easy to get
it to be named as `dArray`, just as it was before. Of course,
adding additional nested type to allow NatVis to know about
actual type would be great as well, as for no reason it ignores
pointer type and thinks it's `void*`, so we would need an
additional cast in NatVis. With that simple change, next NatVis
file would totally work as you expect:
https://www.dropbox.com/s/t5yejma3w7cbna9/dlang.natvis?dl=0
Which might be a best we can get to make VS Code experience on
Windows with DMD and debugging more comfortable. I hope it will
be useful addition to D ecosystem for others as well.
