In Dart, we initially response to setBreakpoints with verified:false. When the VM resolves the breakpoint locations, we send a breakpoint update with verified:true and the resolved location. This usually only happens just before the code first runs (libraries are lazily loaded).
The nvim-dap client treats verified:false as invalid, warning "Server rejected breakpoint":
https://github.com/mfussenegger/nvim-dap/blob/1c63f37f95cd4fb54512898168138d9a75d1516a/lua/dap/session.lua#L887-L888
My feeling was that Dart was doing the right thing (it seemed to work well in VS Code, breakpoints being greyed until their locations resolved), but re-reading the spec I'm less sure:
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.
"could be successfully created" makes it seem like it's used for failure, but it also probably doesn't make sense to update a breakpoint later if it failed. Could this be clarified in the spec? Is using verified:false temporarily until the location is resolved a valid use, or should we send verified:false and just update the location (if required) later?
In Dart, we initially response to
setBreakpointswithverified:false. When the VM resolves the breakpoint locations, we send a breakpoint update withverified:trueand the resolved location. This usually only happens just before the code first runs (libraries are lazily loaded).The nvim-dap client treats
verified:falseas invalid, warning "Server rejected breakpoint":https://github.com/mfussenegger/nvim-dap/blob/1c63f37f95cd4fb54512898168138d9a75d1516a/lua/dap/session.lua#L887-L888
My feeling was that Dart was doing the right thing (it seemed to work well in VS Code, breakpoints being greyed until their locations resolved), but re-reading the spec I'm less sure:
"could be successfully created" makes it seem like it's used for failure, but it also probably doesn't make sense to update a breakpoint later if it failed. Could this be clarified in the spec? Is using
verified:falsetemporarily until the location is resolved a valid use, or should we sendverified:falseand just update the location (if required) later?