uPSDebugger: add HasCodeAtRow for exact breakpoint-line testing - #319
Open
TetzkatLipHoka wants to merge 1 commit into
Open
TetzkatLipHoka wants to merge 1 commit into
TetzkatLipHoka wants to merge 1 commit into
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
…-line testing An IDE integrating the debugger needs to know whether a given source line can carry a breakpoint, i.e. whether any bytecode maps to that line. The debug position table already holds this information (per procedure, a list of FileName/Position/Row/Col records), but there was no public way to query it by row - callers had to either walk the private tables or fall back to a text heuristic that cannot tell a declaration body or comment from real code. HasCodeAtRow(Row, Fn) returns True when any procedure has a position entry for that source row (Fn '' matches any module). It is a small read-only scan of the already-loaded position tables; it returns False when no debug data is loaded. Verified DCC32/DCC64: against a compiled script the table correctly reports executable lines True and declaration / begin / blank lines False. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
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
1 participant
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.
Adds TPSCustomDebugExec.HasCodeAtRow(Row, Fn) - a public, read-only query
answering "can a breakpoint sit on this source line?" by scanning the debug
position tables that are already built during LoadDebugData.
Why
An IDE/editor integrating the debugger has to decide, per source line, whether
to offer a breakpoint (gutter glyph, F5 toggle). The information is exact in
the position table - every opcode records its source row - but there was no
public accessor: callers had to walk the private FDebugDataForProcs tables
themselves, or fall back to a text heuristic that cannot distinguish a
declaration body, a comment or a continuation line from real executable code.
What
A small scan of the loaded tables; returns False when no debug data is loaded.
No new state, no behavior change to existing methods.
Verified
DCC32/DCC64: against a compiled script the table correctly reports executable
lines True and declaration / begin / blank lines False (exactly what a gutter
needs). Trivial portable Pascal - no Exit(value)/generics.
🤖 Generated with Claude Code