No-statement breakpoints are marked as valid

[TicClick]

What version of Go, VS Code & VS Code Go extension are you using?

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.
  • go version go1.17.5 darwin/amd64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
  • https://pastebin.com/NdApxEB9
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.

  • 1.63.2
    899d46d82c4c95423fb7e10e68eba52050e30ba3
    x64
    

• Check your installed extensions to get the version of the VS Code Go extension
  • v0.30.0
• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.
  • https://pastebin.com/fGEwDV2b

Share the Go related settings you have added/edited

(there's none)

Describe the bug

there is no persistent indication that a breakpoint is set on a line without any statement.

Steps to reproduce the behavior:

1. set a breakpoint manually by clicking to the left from the source code. make sure it's on an empty line.
2. run the debugger as per usual.

from the editor, there is no indication that the breakpoint will not be accepted by dlv:

• the breakpoint is displayed as valid (bright red)

• during the debug run, it flashes white very briefly, but is silently skipped. there is zero diagnostic from dlv:

  output from the debug console

  Starting: /Users/whatever/go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:53030 --log-dest=3 from /Users/whatever/development/lazygit
  DAP server listening at: 127.0.0.1:53030
  Type 'dlv help' for list of commands.
  (stacktrace from the application I was trying to debug)
  Process 92361 has exited with status 1
  Detaching
  dlv dap (92344) exited with code: 0
  

meanwhile, dlv informs me when I run it manually that a breakpoint is invalid:

blah ~/development % /Users/whatever/go/bin/dlv exec ./lazygit/lazygit -- --work-tree lazygit
Type 'help' for list of commands.
(dlv) break /Users/whatever/development/lazygit/pkg/commands/git.go:70
Command failed: could not find statement at /Users/whatever/development/lazygit/pkg/commands/git.go:70, please use a line with a statement
(dlv) exit

[hyangah]

Please see #1840
We considered to output the error messages or popups to warn users. However, that would break multi-session debugging workflows badly because it's normal for vscode to send invalid breakpoints to every debug adapter of each debug session.

One way to verify breakpoints is to use stopOnEntry.

[TicClick]

a follow-up question: if the launch.json configurations, which are automatically generated, are also suggested by the extension, could you consider adding (or at least mentioning) stopOnEntry there? I realize that the point you brought up is fair, and I should probably know better than set empty breakpoints, but in this case the decision to not show any validation from dlv actually shadows what's going on in the background.

[hyangah]

cc @suzmue @polinasok

Another thought:

Command failed: could not find statement at /Users/whatever/development/lazygit/pkg/commands/git.go:70, please use a line with a statement

This specific case is clearly an error that belongs to this debug session because the source file is valid, but it's a line that can't be used for breakpoint. In this case, wonder if we can output an error message.

adding (or at least mentioning) stopOnEntry

There are so many optional properties that adding all of them in the template would be confusing. Then the question will be whether we should consider stopOnEntry special and promote it to be in templates.

[hyangah]

We will investigate if we can distinguish the root cause and try to output error message in this specific case (where breakpoint in non-statement line) first.

--
BTW, I want to clarify:

in this case the decision to not show any validation from dlv actually shadows what's going on in the background

Actually, dlv dap reports back the list of invalid breakpoints to the editor but VS Code clears the info as soon as the debug session ends. :-(

[polinasok]

We will investigate if we can distinguish the root cause and try to output error message in this specific case (where breakpoint in non-statement line) first.

We talked about printing to console in #1840, but there were concerns of spamming with irrelevant messages.
But since these messages are distinct, singling this out to log to Debug Console seems straightforward. For example, with "trace":"trace" from Go Debug channel:

[Trace - 24:00:31.205] client  <- {"seq":0,"type":"response","request_seq":4,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"verified":false,"message":"could not find statement at /Users/polina/go/src/hello/hello.go:30, please use a line with a statement","source":{}}]}}

[Trace - 24:00:31.206] client  <- {"seq":0,"type":"response","request_seq":5,"success":true,"command":"setBreakpoints","body":{"breakpoints":[{"verified":false,"message":"could not find file /Users/polina/go/src/issue2844/main.go","source":{}}]}}

in this case the decision to not show any validation from dlv actually shadows what's going on in the background

Actually, dlv dap reports back the list of invalid breakpoints to the editor but VS Code clears the info as soon as the debug session ends. :-(

If you use stopOnEntry or hit some breakpoint or pause, you will note different markers for validated vs invalid breakpoints. You can hover for error. Unfortunately, those details disappears as soon as the session is over.