Proposal: Add new reason `finished` or `stepOut` and optional field `returnValue` to `Stopped Event` about debug-adapter-protocol HOT 6 OPEN

I personally find the ‘put the return value in the scopes’ to be a hack that’s only sporadically implemented and not intuitive for users. I would like to offer a better ui to my users.

The obvious UI for this is to inline it as an inlay hint or virtual test next to or around the function call. This is not trivial and I don’t think there’s enough info in the proposal for clients to implement that well.

In order for this to work well we would need it whether the user pressed step out or step over etc. (Parity with the ‘scopes’ approach). It could be enough just to provide a variablesReference and sourceReference/line number or something.

In summary I think it would be a good addition, but needs more iteration on the UI side to decide what data are worthwhile.

Alternatively, a statement that “typically the return value from the last function call should be reported as a Scope named ‘return’” might help with consistency for users.

from debug-adapter-protocol.

Alternatively, a statement that “typically the return value from the last function call should be reported as a Scope named ‘return’” might help with consistency for users.

This would definitely be an improvement -- for my gdb implementation, I was completely unaware that this was a convention.

Adding a variable reference to the stop event also seems reasonable to me.

Alternatively I suppose an adapter could also do this via an output event. (Though again, the key thing is to document any such convention.)

from debug-adapter-protocol.

Output event is very bad. Probably not even visible to user in most cases.

from debug-adapter-protocol.

The purpose of the step reason is to disambiguate the reason if an event interrupts a step that the client previously sent. For example, if I step over an instruction but have a data breakpoint that's hit before we'd normally pause on the next instruction. In cases where step is given as the reason, the client will already know in which direction the step happened, so I'm not sure the value in specifying beyond that.

For the return value, the way most DA's do this today is adding the return value to the first scope when the return value is present, for example in VS Code's Python debugger:

If we have an explicit DAP-level return value, is there a better experience you envision that clients would want to implement?

from debug-adapter-protocol.

I guess this work just as well.

I suppose one way my proposed way would be preferred, is if in some universe, someone decides to log return values from a function (or set of functions). Automating this process would probably be easier if a "return value" was standardized in the protocol from stepOut, but even in that universe, that functionality could be solved using the same approach as you mentioned.

So I guess we can close this issue really.

from debug-adapter-protocol.

Hm, nothing in particular comes to mind for usages of it in VS Code's UI (cc @roblourens) but let's leave it open for a bit to see if any other client implementors want to weigh in.

In general DAP is a protocol for specifying what UI should be available during debugging, so most of our thinking starts at the client experience we want to build, and from there the minimal protocol necessary to describe it.

from debug-adapter-protocol.