debug: fallback to mark breakpoints verified on stopped/breakpoint events

[amanthatdoescares]

Description

LLDB-DAP sometimes fails to mark breakpoints as verified in the setBreakpoints response, even though the breakpoint is hit during debugging. This leads to the VS Code UI showing the breakpoint as “unverified” while execution actually stops there.

This PR adds a safe fallback that marks breakpoints as verified when we detect them being hit via:

• a stopped event with reason: "breakpoint", or
• a breakpoint event containing a valid source and line.

This improves consistency between actual debugger behavior and the UI, especially for Swift executables and swift test.

Issue: #1871

Tasks

• Required tests have been written
• [ ] Documentation has been updated
• Added an entry to CHANGELOG.md if applicable

[award999]

@amanthatdoescares thanks so much for the PR 🙏 I have some initial comments here to get you started. @matthewbastien is more familiar with the debugging codebase so let's have him take a look to.

Also the open todo for updating changelog in the PR template, you just need to do something like 85d5132, but this being a bug fix, you'd put it under the ### Fixed section for the latest release.

[matthewbastien]

Thank you for fixing this! I just have some minor comments to make the code easier to read.

[matthewbastien]

question: Will this also trigger when the breakpoint is already resolved? It's probably not a huge issue, but I think we should be only doing this when the breakpoint that's being hit isn't marked as resolved.

[matthewbastien]

chore: You'll have to rebase this since the CHANGELOG was recently updated for version 2.14.2. This may require moving this bullet to a new ### Fixed section.

[amanthatdoescares]

Will do — I’ll rebase and move the entry to the current unreleased ### Fixed section.

[matthewbastien]

Thanks! The location looks good now.

Though I just noticed that the wording here would only be meaningful to contributors and probably won't make much sense to users of the extension. Maybe we could go with something like Fixed breakpoints showing up as unresolved when using lldb-dap?

[matthewbastien]

@amanthatdoescares I tried this out locally with Swift 6.2.0 and it looks like the logic isn't working. My breakpoint is not being resolved despite the debug session stopping at the breakpoint. Debugging through the tracker code you added shows that the breakpoint coming from the DAP does not have a source path and so the code is just ignoring it.

What version of Swift did you test this with locally? There might be some differences in lldb-dap between that and the version I tested with?

I'd like some integration tests to be added for this before we can merge. Preferably by starting a debugging session with a breakpoint and then making sure that it gets resolved once hit.

[amanthatdoescares]

@matthewbastien Thanks for the detailed review. After looking at it again, I realized I completely missed the real issue. My fallback logic only handles the happy case where the DAP breakpoint includes a source.path, and I didn’t actually test the scenario you ran into — the one where the adapter sends a breakpoint without a path. So the code ends up ignoring exactly the situation it was supposed to fix. Definitely a blooper on my part.

It’s clear now that this isn’t an environment/version difference — the logic just isn’t handling the missing-path case at all.
I’ll take another pass at this with the right approach:

• Reproduce the behavior properly and capture the actual setBreakpoints request + the breakpoint event.
• Fix the resolution logic so it works even when the adapter doesn’t provide a source.path.
• Add the integration test you mentioned: start a debug session with a breakpoint and assert that it gets verified once hit.

I’ll update the PR once I’ve got the full flow working as intended. Thanks again for pointing out.