service/dap: support setting breakpoints while running #2472
Conversation
|
Failing test is TestAttachStopOnEntry, which I am hopefully fixing in the other PR #2476 |
service/dap/server.go
Outdated
| if inProgress == api.Continue { | ||
| s.overrideStopReason <- skipStop | ||
| } else { | ||
| // This would be one of the step commands, which get cancelled by debugger. |
There was a problem hiding this comment.
There is no necessity for this logic. All step commands can be resumed, like continue and rewind by issuing a api.DirectionCongruentContinue command.
There was a problem hiding this comment.
From my reading of the code in proc, when a step /next request is manually halted ClearInternalBreakpoints is always called.
It would be great if there is a way to be able to continue next requests, this is also a feature I am interested in for implementing logpoints.
There was a problem hiding this comment.
We had this conversation a while back when trying to fix setting breakpoints in the old adapter:
golang/vscode-go#787 (comment)
I too saw ClearInternalBreakpoints and understood it as halt cancelling step.
There was a problem hiding this comment.
What's a logpoint? Anyway it shouldn't be to hard to make a variant of halt that sets a flag so that ClearInternalBreakpoints isn't called in proc.(*Target).Continue.
There was a problem hiding this comment.
A log point is like a trace point but with user supplied message
From DAP spec for setBreakpoints arguments:
/**
* If this attribute exists and is non-empty, the backend must not 'break'
* (stop)
* but log the message instead. Expressions within {} are interpolated.
* The attribute is only honored by a debug adapter if the capability
* 'supportsLogPoints' is true.
*/
logMessage?: string;
Unlike vscode-go, this implementation does not resume execution after halting and setting breakpoints. Resuming automatically turns out to be much trickier than just skipping a stopped event and continuing. It is possible that the stop occurred due to reasons other than our manual stop (breakpoint, call return), so we would need to detect thtat and report any stops that the user might be interested in. In addition, next would be cancelled by the halt command, so to resume it, we would need to implement an alternative version of halt that doesn't cancel next. So for now, we will just be reporting the pause to the user and let them decide when and how to resume execution manually.
Updates #1515
Updates golang/vscode-go#1475