Natvis, CV8, dAssocArray

Void-995 void995 at gmail.com
Thu Sep 27 16:52:25 UTC 2018


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.


More information about the Digitalmars-d-debugger mailing list