Natvis, CV8, dAssocArray

Rainer Schuetze r.sagitario at gmx.de
Fri Sep 28 16:32:36 UTC 2018



On 27/09/2018 18:52, Void-995 wrote:
> 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:
>>> 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.

Reminds me of autoexp.dat, the predecessor of NatVis. With a little help 
from cv2pdb I managed to show slices and AAs in the C++ debugger aswell, 
but it was horrible to figure out as the debugger crashed if there was 
something unexpected in the visualizer macros, needing a bunch of 
workarounds. I guess this has improved with NatVis, has it?

You could also capture the type of template arguments in the type name. 
Doesn't NatVis feature this, too? That should allow casting the slice 
pointer (though the debug info should be correct, too).

autoexp.dat macros were also pretty slow, so showing a larger AA could 
cause the debugger to grind to a halt. How does NatVis perform?

For a more advanced problem: show the value of `aa["7"]` in the watch 
window ;-)


More information about the Digitalmars-d-debugger mailing list