fix(#467): surface unbound breakpoints at exit; auto-qualify go's bare 'main' - #484
Merged
Conversation
…e 'main'
Case 1: a launch that ends in STOPPED with breakpoints that never bound
now says so in the start_debugging response warning, listing each
breakpoint with the diagnostic the store already holds (e.g. CodeLLDB's
valid-location path suggestion). Built only at ran-to-completion, where
unverified means never-will-bind even for bind-late adapters — zero
false positives.
Case 2: a bare function-breakpoint name the policy KNOWS can never bind
is rewritten instead of stored as a permanently dead breakpoint. New
policy hook normalizeFunctionBreakpointName; go rewrites 'main' ->
'main.main' (func main must live in package main, so the qualification
is certain) and the response carries requestedName + a warning saying
the rewrite happened. Other bare names keep the advisory hint — their
package is not knowable.
Verified live: go set_breakpoint {function:"main"} now binds and stops
at main.main (previously ran to completion); a js launch with a
never-loaded file's breakpoint returns the unbound warning on the
start_debugging response.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #467.
Case 1 — the run that silently didn't work now says so
A launch that ends in
stoppedwith breakpoints that never bound gets awarningon thestart_debuggingresponse listing each unbound breakpoint with the diagnostic the store already holds (e.g. CodeLLDB's "a valid location was found at …" path suggestion the issue highlighted). Built only at ran-to-completion — where unverified means never-will-bind even for bind-late adapters — so it cannot false-positive on js/java's designed late binding. Stored js-debug l10n keys are translated before surfacing (#471's normalizer).Case 2 — a breakpoint the server knows is dead is fixed instead of stored
New policy hook
normalizeFunctionBreakpointName(issue options 1+2 composed): a name the policy is certain can never bind as given is rewritten, and the response says so. Go rewrites baremain→main.main— the qualification is certain becausefunc mainmust live in package main — returningrequestedName: "main",functionName: "main.main", and a warning explaining the rewrite. Other bare names keep the existing advisory hint (their package isn't knowable), unqualified-but-uncertain stays warn-only.Verification (live)
set_breakpoint {function: "main"}+ launch → binds and pauses atmain.main(previously ran to completion with a dead breakpoint in the list).state: "stopped"+warning: "1 breakpoint(s) never bound during this run: attach_target.js:5 (Unbound breakpoint). The program ran to completion without stopping there — …".🤖 Generated with Claude Code