Suspend breakpoint if file is not found

[LittleChimera]

This is a follow-up from #3390

Any breakpoints for which the file is not found will be suspended by default. These should usually be any breakpoints that are defined in the plugin code. that are not verified will now get suspended by default. This seems to resolve the issue in VSCode: golang/vscode-go#2775

TODO:

• add a test

[aarzilli]

I think it's fine to just call CreateBreakpoint with suspended == true here, but you still have to say that the breakpoint is unverified if it does indeed end up being suspended: the user needs some kind of feedback for breakpoints that can't be enabled, it could be that they are enabled by a plugin later, but it could also be that they are just being set on a line that isn't in the executable.

[aarzilli]

Also, what does the protocol say we should be doing when a previously unverified breakpoint becomes verified?

[LittleChimera]

I think it's fine to just call CreateBreakpoint with suspended == true here,

this part would fail without the additional check: https://github.com/LittleChimera/delve/blob/suspend-non-verified-breakpoints/service/dap/server_test.go#L2896-L2898

but you still have to say that the breakpoint is unverified if it does indeed end up being suspended:

i was thinking to just take the latest error for example, or combine them with errors.Join

however, as you asked, we'd need to find some way to update them to verified once the plugin is reloaded. although, we could consider implementing this in another PR since it doesn't seem to affect the functionality in VSCode for example (the only difference is error message on hover).

from the DAP docs:

If a debug adapter is unable to apply a breakpoint at the time when it’s first sent, it should mark the breakpoint as unverified using verified: false in the SetBreakpointsResponse. If the breakpoint changes its state at a later point in time, the debug adapter should use the breakpoint event to notify the client.

The verified property of a Breakpoint object signals whether the exception breakpoint or filter could be successfully created and whether the condition is valid. In case of an error the message property explains the problem. The id property can be used to introduce a unique ID for the exception breakpoint or filter so that it can be updated subsequently by sending breakpoint events.

[aarzilli]

this part would fail without the additional check: https://github.com/LittleChimera/delve/blob/suspend-non-verified-breakpoints/service/dap/server_test.go#L2896-L2898

True. We probably want to keep the error, something like this then:

got, err = s.debugger.CreateBreakpoint(bp, "", nil, false)
if err != nil {
	// try to create a suspended breakpoint instead
	got, _ = s.debugger.CreateBreakpoint(bp, "", nil, true)
}