debug: option to disable the modal dialog on launch failure

[hyangah]

This is a resurrection of the original feature request #48606
(Previously discussed in microsoft/vscode-go#1644 in microsoft/vscode-go,
but we are still getting the same requests from users golang/vscode-go#1375)

The feature request microsoft/vscode-go#1644 filed in microsoft/vscode-go
repo was rejected, I am afraid there was some misunderstanding during the discussion.

Go's debug adapter&debugger (delve dap) does not only launch the debugee upon a launch request,
but also performs the compile/build of the target binary. That is different from debug workflows of
other languages that usually separate build steps from debug launch steps.
When build fails, the adapter returns error for the launch request
(we couldn't build due to compiler errors so we couldn't launch!), which results in the modal popup.

Revisiting @weinand's original comment #48606 (comment)

I think there are two types of notifications:

• expected (frequent) problems like compiler errors,
• unexpected (rare) problems like a runtime error in a debugger or a non-existing variable in a launch config.

IMO the first type of problem should be addressed by the non-modal notification whereas the second type
should result in a modal dialog because it is a fundamental problem that requires the users attention.

So, I'd say Go's debug extension current behavior doesn't match the expected UX.

Is there any workaround in DAP to implement this in vscode-go side?
Separating the compile step from the launch as a pre-launch task is not ideal for Go
since we depend on Delve's decision on how to build the target with sufficient debug info.

Can we have an option to disable the modal dialog depending on the types of launch failures?

cc @polinasok @suzmue @isidorn

ps. I tried to use the showUser property (set to false), but that just controls the extra notification popup currently.

[polinasok]

Here is a sample log of the request-response traffic that results in the dialogue.

From client: initialize({"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"go","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true,"supportsInvalidatedEvent":true})
To client: {"seq":0,"type":"response","request_seq":1,"command":"initialize","success":true,"body":{"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":true,"supportsSetVariable":true}}
From client: launch({"name":"Launch file","type":"go","request":"launch","program":"/Users/polina/go/src/temp.go",...}}
To client: {"seq":0,"type":"response","request_seq":2,"command":"launch","success":false,"message":"Failed to continue: Check the debug console for details.","body":{"error":{"id":3000,"format":"Failed to continue: Check the debug console for details.","showUser":false}}}

I guess we could send a terminated event followed by successful launch response or maybe even no response while printing the error details to the console to avoid the pop-up, but that seems like a hack.

I think it would be much cleaner for vscode to either honor showUser or to have a global setting to turn these pop-ups on and off.

[polinasok]

@weinand Any updates? We have a draft PR, but it is too hacky to put inside of the delve debugger and negatively impacts clients that do not have this problem. Next step would be to move the hack into the vscode-go extension, intercepting the launch error response and replacing it with a success response + terminated event to trick vscode editor into not showing the window, but we would much rather avoid any such hacks if a mechanism is coming on your end soon. Thank you.

[weinand]

I think it is not a good idea to run the compile/build as part of DAP's launch request (and not as a separate task). Communicating compile/build errors to the user via the debug console is not a good user experience. I would expect that compile/build problems show up in the problems view and I can easily navigate from there.

I cannot really follow your argument:

Separating the compile step from the launch as a pre-launch task is not ideal for Go
since we depend on Delve's decision on how to build the target with sufficient debug info.

Debugging compiled languages always depends on compile/builds with sufficient debug info. But the C++ or C# extension compile/build as a prelaunch task and not as part of DAP launch and they never complained about this.

But given that you don't want to change this, let's try to find a solution.

So your ask is basically this:

The DAP "launch" request should fail without a modal dialog if the reason was a compile/build error.

I see two options:

• in case of a compile/build error in the "launch" request, the Go DA sends the error information to the debug console but does not return an error from the "launch" request to make VS Code continue the session normally. After the initialisation sequence is done, the Go DA sends a "Terminated" and "Exited" events to stop the debug session. This would not require any changes in clients (e.g. VS Code).
• VS Code only shows a modal dialog if the "showUser" property of the error message exists and is false. If "showUser" is missing, we would behave like before in order to preserve compatibility.

@isidorn @roblourens what do you think? Do you see other options?

[isidorn]

VS Code only shows a modal dialog if the "showUser" property of the error message exists and is false. If "showUser" is missing, we would behave like before in order to preserve compatibility.

I think this would work and would not be a large change.
For reference here's a place where I think we show the modal dialog https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/browser/debugService.ts#L836

[hyangah]

I think it is not a good idea to run the compile/build as part of DAP's launch request (and not as a separate task). Communicating compile/build errors to the user via the debug console is not a good user experience. I would expect that compile/build problems show up in the problems view and I can easily navigate from there.

The build diagnostics show up in the problems view almost real time (thank to the language server) but I observed many users prefer continuous testing rather than switching among the problems view, debug console, and terminal.

Debugging compiled languages always depends on compile/builds with sufficient debug info. But the C++ or C# extension compile/build as a prelaunch task and not as part of DAP launch and they never complained about this.

Maybe it's because go's tool chain is generally much easier to use so requiring a separate make file or configuration is not part of the common go dev workflow. For example, dlv test is modeled after go test command that takes either file path, directory path, or even package path, builds the test binary, and runs the test binary from the package directory. No more than one command is needed. In addition to what go test does, dlv test detects the go version user in use and provides the additional flags to include additional debug info which may vary depending on the go version. We may choose to let the extension duplicate what dlv would do and provide a pretask, but I think it's better to keep all this knowledge centralized in dlv and debug adapter (for vscode-go and other editors' plugins)

VS Code only shows a modal dialog if the "showUser" property of the error message exists and is false. If "showUser" is missing, we would behave like before in order to preserve compatibility.
I think this would work and would not be a large change.
For reference here's a place where I think we show the modal dialog https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/debug/browser/debugService.ts#L836

It sounds like the best option for us :-)

[weinand]

@isidorn ok, let's do this.