Add Logpoints support

[lggomez]

Logpoints are a special kind of breakpoint provided by VS Code that just logs messages unpon being hit, instead of stopping and showing the current stack trace/frame information

The difference between a regular breakpoint and a logpoint seems to be in this property: https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/debug/common/debugProtocol.d.ts#L1413-L1414

We could support this although I'm still not sure on how to bypass the SetBreakPointsRequest delve apicalls and still be able to track the logpoints

This belongs to the SourceBreakpoint interface so I guess it is related to #1676

[ramya-rao-a]

This would be a cool thing to explore. Am out on vacation next week, will get to this once am back.

[Nox-404]

Hello there,
I'll need that too, please implement this :)

[danj565]

This would be an amazing enhancement!

[hyangah]

@quoctruong @polinasok Can you please take a look? Can this be implemented from Delve side?

[lggomez]

I can give it a look, this shouldn't need any changes on the delve side, aside from the fact that CreateBreakpoint doesn't have anything explicit (that I know of) to enable us to build this feature: https://godoc.org/github.com/derekparker/delve/service/rpc2#RPCServer.CreateBreakpoint

This is the current spec, and the following is found about logpoints on the SourceBreakpoint interface:

  /**
   * 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;

If delve doesn't handle this, we can still hack it on our side, bu we´ll have to keep transient state about these breakpoints so we handle them differently (just log and return) upon debugger callbacks

[hyangah]

@lggomez Another thing to consider is the new DAP support from delve side.
https://github.com/go-delve/delve/tree/master/service/dap The Go extension is not yet using the DAP but we will switch eventually. So, I'd first discuss this with delve dev whether it makes sense for delve to provide this feature.

[lggomez]

@hyangah Nice, I wasn't aware of this work in progress, having a DAP compliant service will iron out most of the current frictions with the v2 API surface (and hopefully the performance issues)

When I commented that delve wouldn't require changes is for the most conservative and basic case which is logging text-only messages from the adapter. To provide full support for logpoints, delve should receive a message containing either:

• A well defined pair of messages, the layout and the local variable parameters; i.e: "hello %s", foo
• A complete function call which does this capturing said local variables: fmt.Sprintf("hello %s", foo)

Both both vary the implementation but on an API level I think the requirement is more or less the same, since we'll be constrained by the standard fmt placeholders for interpolation

[danj565]

Would you like me to open an issue with Delve? Has the go extension implemented the DAP service yet?

Thanks for the great extension. Having log points would make debugging our websocket apps a lot easier.

[activeshadow]

Does anyone have a timeline for this feature? I will by no means pretend to even have the slightest clue about how the Go development extension works at the TypeScript code level, nor the complexity of the extension, nor the complexity of the interaction with Delve, but even as a MVP for this feature it would be awesome if a log point simply evaluated the configured expression and automatically continued on with program execution (as opposed to the user having to manually hit the "play" button). I know this would require tracking log points separate from breakpoints in the extension to know if program execution should be automatically continued, so again I'll reiterate my lack of a clue about whether or not this is currently even possible or how complex it would be.

Ultimately, I currently find myself adding log messages to my code, recompiling, redeploying to the cloud, etc. over and over again when debugging certain types of issues / code execution flow. The ability to deploy a debug version of my app, running via Delve, to the cloud one time and dynamically being able to add logging via log points would be, for lack of a better term, SWEET!!!

Regardless, I want to express my appreciation for the maintainers of the Go extension. 👏👏👏

[ramya-rao-a]

Hello all,

We are in the midst of a repo move, see We are moving section in our readme for more details.

Closing this issue in favor of golang/vscode-go#123. Please subscribe to it for further updates and upvote it as well

Thanks for all the support & Happy Coding!