Description
Related issues: #336, #1027, #313, #23 (comment)
Related vscode documentation: https://code.visualstudio.com/api/references/vscode-api#DebugSessionOptions, microsoft/vscode#104986
Merging the disjoint, but overlapping conversations we have had about the proper mechanism for noDebug support into a dedicated issue. So where does noDebug handling belong? Extension? DA? Debugger?
Currently, in both adapters we handle launch+debug separately from others (test, exec) to bypass delve - see debugAdapter -- launch, disconnect and debugAdapter2 -- launch, disconnect.
Here is what I just learned from @weinand:
The "noDebug" feature is an optional hint to the debugger to run the program without hitting breakpoints and breaking on exceptions. It is not necessarily meant to run the program "outside of the debugger" with "full speed".
We've introduced the "noDebug" feature as a cheap way to provide a generic "run": if a user has created a launch config for debugging, it should be easily possible to use that for running the program without debugging.
Without that feature, VS Code would have no generic "program runner".
For that reason, some language extensions provide their own program runner that does not involve a launch configuration or a debugger/runtime. With that approach they basically support "Run", "Debug", and "Run without Debugging".In your case you have two options:
- use the "Run without Debugging" approach and don't bypass dlv but just disable its debugging (if possible). Provide a separate "Run" command for running the Go program with full speed.
- in your extension implement the "DebugConfigurationProvider.resolveDebugConfiguration" hook and if the "noDebug" property is true, create a command from the launch configuration and execute it. Returning "undefined" from "resolveDebugConfiguration" stops VS Code from continuing the debug session.
So according to this, it is perfectly valid to move the run-without-debugging logic from the DA to the extension (something we considered as part of dlv-dap integration without thin adapter - #23) or to channel the no-debug case through delve while "disabling its debugging". We can easily skip setting user-specified breakpoints set, but would also need to update delve to skipping its internal breakpoints for panic and such.