Type information proposal about debug-adapter-protocol HOT 5 CLOSED

What is the advantage of having this in the debug protocol as opposed to just opaque output sent as an OutputEvent in response to an evaluation?

from debug-adapter-protocol.

One possible use case would be if you wanted to implement a type information browser in your debugger client that the user could interact with in a similar way as (for example) the Class Browser in Visual Studio. You would not want such a user interface to simply request all type information though because it would be a huge amount of data sent over the wire. So instead, the user might be able to enter a type name, or part of a type name, and then have some kind of tree view built up which the user could explore.

To come up with more examples, I think I need to understand exactly what you mean by "in response to an evaluation" though. Do you mean "in response to an Evaluate request?" Because I was under the impression that that request was reserved for evaluating expressions in the context of a stack frame. So you might get an evaluate request for something like (foo[0]->*pfn)(42) but not for some arbitrary debugger command like dt MyType. Am I mistaken here? I guess it could be possible for an adapter to implement this with an extension syntax like !!myadapter!!dt MyType and the adapter could handle this specially. That seems like not the intended use case for the Evaluate request though, so I'm not sure if it's what what you had in mind.

from debug-adapter-protocol.

You could think of the debug console in VS Code or the immediate window in VS as a window that accepts a line of text from the user and evaluates it. Certainly normally this would be some sort of expression in the context of the current stack frame, but the UI doesn't understand this, so you could certainly also accept commands. The VS Code C++ debugger for example accepts arbitrary GDB commands this way. You could certainly imagine doing this with windbg as that is exactly how the windbg command window works.

from debug-adapter-protocol.

I guess the only other thing I can think of is that it could help to implement a visualizer language in your debugger client if the debugger client had type information. Otherwise, it becomes the responsibility of the debug adapter to provide visualizers, which means that users will get a different experience for every debug adapter they try to use, rather than having 1 visualizer syntax that just works regardless of debug adapter.

from debug-adapter-protocol.

A fundamental principle of the debug adapter protocol (DAP) is to only support "strings for rendering" a debugger UI.
DAP was not designed for extracting fine-grained type information about the runtime representation of the program to be debugged.

So if you want to convey type information via DAP you can extend the protocol privately and use it between your client and your debug adapter. But we will not make this type information protocol official part of DAP.

from debug-adapter-protocol.