Better Native Pointer Debug Views

[LostTime76]

Is your feature request related to a problem? Please describe.

I am trying to implement native bindings to a library that extensively uses pointers to objects. I am trying to build custom views using the DebuggerDisplay and DebuggerTypeProxy attributes; however, no matter what I do, I cannot get the vscode debugger views to display the objects how I want. I have tried many combinations but to no avail. The debugger views just do not like native pointers at all.

Describe the solution you would like

I have run into a few issues with the debug views that seem unsatisfactory:

1. The debugger view does not display the type of a pointer type at all (ex: Foo*). I have also noticed that many 'special' characters specified in the Type property of the DebuggerDisplayAttribute cause the type name for the variable to disappear in the same way: * being one of them. I think the type name should be displayed regardless of what characters the type string contains. I tested Foo* with visual studio and it correctly displays the type name
2. For a pointer variable in the debug view (ex: Foo*) expanding the variable reveals a dereference operation. For what I am doing, this makes absolutely no sense and I would not like the view trying to dereference the pointer and show me the result. The pointers in question are a combination of some base structure fields and opaque pointers. Provide some sort of attribute or option to tell the debug view to not try and display a dereferenced pointer.
3. If we try to apply the DebuggerTypeProxyAttribute to a pointer type at the assembly level, we can provide a custom view for the pointer by dereferencing the pointer properly for the application and providing the debug fields. Problem is that when you apply the DebuggerTypeProxyAttribute to a pointer type wherein the type itself is a structure, the view tries to provide a dereferenced 'raw view' of the pointer. Again, I don't want the view dereferencing the pointer and or trying to provide a raw view. Provide an option to completely disable the raw view display.
4. I potentially want a custom type (that is not a pointer) to be viewable through the "view binary data" button so we can view the raw memory for the variable. I have tried almost everything to try and get that button to appear for my custom type to no avail. The button appears for pointer types and just about every other type, but there seems to be no way to tell the debug view how to get a pointer to memory for a custom type and display the button. Provide a way for a type to tell the debug view about a memory pointer it can use to open the binary memory view through the 'view binary data' button.

Applicable Scenarios

Better native pointer debug view support / customization

Describe alternatives you've considered

Trying to hack DebuggerTypeProxy & DebuggerDisplay attributes with different combinations

Additional context

[gregg-miskelly]

@LostTime76 Would you mind opening a separate issue for 1? That one seems like a bug, where as the others I believe are all part of a feature request for better pointer handling across the Visual Studio family of products.

For 2: Have you considered using a struct to wrap IntPtr if you want an opaque pointer-sized value that you can format specially?

[LostTime76]

The two main options I have are to use 'unsafe' pointers directly or to wrap a single field into a struct like you are suggesting. I have investigated both thoroughly and each has a problem:

• For the unsafe pointer, I get the dereference + raw view for the opaque pointer which is not desirable.
• For the struct wrapper, the issue is that while I can DebuggerDisplay the pointer value in hex to make it look like a pointer, I cannot get the 'view binary data' button to appear in the view for the variable. Yes, I can just expose a pointer property on the struct wrapper that when expanded shows the 'view binary data' button; however, its a hack. I do not understand how to get the button to appear for my custom struct variable even though vscode displays it for just about every other type of built in primitive.

After considering the options, the unsafe pointer is what I want instead of the struct wrapper, because the goal is not to hide the pointer / unsafe code from the user, but rather just provide some useful automatic utilities like a custom debug view for the object. Additionally, the struct wrapper is more code and confusion especially if we have more types of opaque like pointers. Users of the library have to use unsafe code and pointers anyways to implement new objects.