Skip to content

signatures: reject BreakpointRef and stray nothing program counters - #168

Merged
aviatesk merged 1 commit into
masterfrom
avi/handle-breakpointrefs
Sep 16, 2026
Merged

aviatesk merged 1 commit into
masterfrom
avi/handle-breakpointrefs

Conversation

@aviatesk

Copy link
Copy Markdown
Member

step_expr! and next_until! return a BreakpointRef when a breakpoint is hit or when JuliaInterpreter.break_on(:error)/break_on(:throw) is active and a statement throws. The method-definition walkers in signatures.jl never handled that case (nor, on some paths, nothing), so pc was inferred as Union{Int,Nothing,BreakpointRef} and, when it did happen, failed later with an unrelated error. Concretely, with break_on(:error) enabled (e.g. via Debugger.jl) Revise reported ArgumentError: invalid index: breakpoint(...) instead of the actual UndefVarError for a typo in a method signature, because Revise's disablebp only disables breakpoint instances, not break_on.

Add throw_if_breakpoint, which rethrows the error carried by the BreakpointRef (what would have propagated without break_on) or raises an error otherwise, and narrows pc to Union{Int,Nothing}. Wrap every step_expr!/next_until! call site with it, handle the remaining nothing cases explicitly (step_through_methoddef, get_running_name, the inner-method loop of methoddef!), and let _methoddefs! accept nothing.

Along the way: assert the MethodInfoKey returned by signature for a 3-arg :method, drop the redundant trailing frame.pc = pc (both step_expr! and next_or_nothing! already advance it, and it would throw for nothing), and report the "no method found" warning at the :method statement pc3 rather than the statement after it.

JET(LS) no longer reports any pc-related issue in signatures.jl; the LoweredCodeUtils and Revise test suites pass.

`step_expr!` and `next_until!` return a `BreakpointRef` when a
breakpoint
is hit or when `JuliaInterpreter.break_on(:error)`/`break_on(:throw)` is
active and a statement throws. The method-definition walkers in
signatures.jl never handled that case (nor, on some paths, `nothing`),
so `pc` was inferred as `Union{Int,Nothing,BreakpointRef}` and, when it
did happen, failed later with an unrelated error. Concretely, with
`break_on(:error)` enabled (e.g. via Debugger.jl) Revise reported
`ArgumentError: invalid index: breakpoint(...)` instead of the actual
`UndefVarError` for a typo in a method signature, because Revise's
`disablebp` only disables breakpoint instances, not `break_on`.

Add `throw_if_breakpoint`, which rethrows the error carried by the
`BreakpointRef` (what would have propagated without `break_on`) or
raises an error otherwise, and narrows `pc` to `Union{Int,Nothing}`.
Wrap every `step_expr!`/`next_until!` call site with it, handle the
remaining `nothing` cases explicitly (`step_through_methoddef`,
`get_running_name`, the inner-method loop of `methoddef!`), and let
`_methoddefs!` accept `nothing`.

Along the way: assert the `MethodInfoKey` returned by `signature` for a
3-arg `:method`, drop the redundant trailing `frame.pc = pc` (both
`step_expr!` and `next_or_nothing!` already advance it, and it would
throw for `nothing`), and report the "no method found" warning at the
`:method` statement `pc3` rather than the statement after it.

JET no longer reports any `pc`-related issue in signatures.jl; the
LoweredCodeUtils and Revise test suites pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@aviatesk
aviatesk force-pushed the avi/handle-breakpointrefs branch from dd1d785 to c2cce1d Compare September 16, 2026 06:13
@aviatesk
aviatesk merged commit 4d257e1 into master Sep 16, 2026
10 checks passed
@aviatesk
aviatesk deleted the avi/handle-breakpointrefs branch September 16, 2026 06:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant