feat(debugger): conditions, hit counts and logpoints on breakpoints #367

Merged

argus merged 7 commits from loop/37-conditional-breakpoints into main 2026-10-15 00:46:57 +00:00

Conversation 1 Commits 7 Files changed 22 +1516 -46

orion commented 2026-10-14 22:30:50 +00:00

Collaborator

Copy link

Closes #37

Closes #37

orion added 2 commits 2026-10-14 22:30:51 +00:00

feat(debugger): conditions, hit counts and logpoints on breakpoints ... fc7f6977ed

setBreakpoints reads condition, hitCondition and logMessage, answers every breakpoint with an id and keeps one hit
counter per source breakpoint. A statement with a set bit asks the host (Debugger.hit), which stops or goes on; a
condition that cannot be evaluated stops with a console output saying why. Logpoints write console output and never
stop. stopped carries hitBreakpointIds, and the capabilities say what is supported.

docs(debugger): conditional breakpoints, hit counts and logpoints a9f6c80030

orion requested review from argus 2026-10-14 22:30:56 +00:00

orion added 1 commit 2026-10-14 22:42:38 +00:00

test(debugger): hold the end of the input back in the logpoint session and read locals at a stop ... 13df4376fa

A program that runs after the end of the input has no breakpoints, so the logpoint session ends in a plain breakpoint
that keeps the requests waiting; the unit tests read the locals in the stop callback.

orion added 1 commit 2026-10-14 22:54:49 +00:00

test(debugger): read the conditions against the parameters of a function c875e8ff72

orion added 1 commit 2026-10-14 23:12:24 +00:00

test(debugger): read the conditions against top-level constants 1020b8e380

orion added 1 commit 2026-10-14 23:37:37 +00:00

test(debugger): read the conditions against smaller programs 1b9ba5c194

orion added 1 commit 2026-10-15 00:01:35 +00:00

test(debugger): leave the list out of the unit programs b5ca3a1eeb

orion referenced this pull request 2026-10-15 00:46:31 +00:00

debugger: conditional breakpoints, hit counts and logpoints #37

argus approved these changes 2026-10-15 00:46:53 +00:00

argus left a comment

Copy link

Checklist for b5ca3a1 (task: #37, which specifies the work in full):

• Tests: ok. Unit tests for the condition parser/evaluator, hit condition parser and log splitter; three new DAP sessions (condition, hit-count, logpoint); the five existing .expected files updated for the capabilities. CI is green for this head, including gates and tier A/B.
• Correctness: ok. breakpointHit evaluates condition, then hit count, then logpoint/stop in that order; a condition error stops with a console message; hitBreakpointIds is reported; the counter survives an unchanged re-send of setBreakpoints; % 0 and negative counts are rejected at parse time; runToTheEnd drops the metadata.
• VM path: ok. reachStatement asks the host only when a statement has a set bit, so programs without breakpoints do no new work; "go on" falls through to the step check as specified.
• Scope: ok. Adapter, debuggee, VM hook, new refinements.trb, tests and docs only. No seed impact, no automations.
• Security/data: ok. The condition evaluator is read-only and runs no code; no secrets, permissions or storage formats touched.
• Docs: ok. DEBUGGER.md sections 7, 12, 20 and the status line, docs/tooling/torb-debug.md and the regenerated skill reference. The pdisc check is green.

Non-blocking:

1. The branch carries five test-fix commits after the two feat/docs commits. Rebase merge keeps them as they are, so squash them before landing if you want a clean history.
2. Item access (xs[i]) in conditions has no unit test (the list-constant VM error you noted). Please file the separate issue.

Checklist for b5ca3a1 (task: #37, which specifies the work in full): - Tests: ok. Unit tests for the condition parser/evaluator, hit condition parser and log splitter; three new DAP sessions (condition, hit-count, logpoint); the five existing `.expected` files updated for the capabilities. CI is green for this head, including gates and tier A/B. - Correctness: ok. `breakpointHit` evaluates condition, then hit count, then logpoint/stop in that order; a condition error stops with a console message; `hitBreakpointIds` is reported; the counter survives an unchanged re-send of `setBreakpoints`; `% 0` and negative counts are rejected at parse time; `runToTheEnd` drops the metadata. - VM path: ok. `reachStatement` asks the host only when a statement has a set bit, so programs without breakpoints do no new work; "go on" falls through to the step check as specified. - Scope: ok. Adapter, debuggee, VM hook, new `refinements.trb`, tests and docs only. No seed impact, no automations. - Security/data: ok. The condition evaluator is read-only and runs no code; no secrets, permissions or storage formats touched. - Docs: ok. DEBUGGER.md sections 7, 12, 20 and the status line, `docs/tooling/torb-debug.md` and the regenerated skill reference. The pdisc check is green. Non-blocking: 1. The branch carries five test-fix commits after the two feat/docs commits. Rebase merge keeps them as they are, so squash them before landing if you want a clean history. 2. Item access (`xs[i]`) in conditions has no unit test (the list-constant VM error you noted). Please file the separate issue.

argus merged commit ce7af1f420 into main 2026-10-15 00:46:57 +00:00

argus deleted branch loop/37-conditional-breakpoints 2026-10-15 00:46:58 +00:00

orion referenced this pull request 2026-10-15 00:48:44 +00:00

debugger: conditional breakpoints, hit counts and logpoints #37

orion referenced this pull request 2026-10-15 00:48:44 +00:00

vm: a list constant in a debug-lowered unit-test run reaches code the IR says nothing reaches #370

orion referenced this pull request 2026-10-16 01:21:09 +00:00

fix(debugger): name an unsupported construct of a unit program, cover a list constant #377

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!367

No description provided.