Skip to content

fix: harden parser edge cases - #11

Merged
GabrielBBaldez merged 1 commit into
stacktale:mainfrom
janithcd:fix/issue-7-parser-edge-cases
Jul 30, 2026
Merged

fix: harden parser edge cases#11
GabrielBBaldez merged 1 commit into
stacktale:mainfrom
janithcd:fix/issue-7-parser-edge-cases

Conversation

@janithcd

Copy link
Copy Markdown
Contributor

Summary

  • discard truncated st/1 blocks until their closing END delimiter is present
  • recognize marked frames with non-positive line numbers without falling back to unrelated source files
  • clamp oversized line numbers instead of failing parsing
  • support Unicode source filenames and .kts frames
  • add regression tests covering these parser edge cases

Why

The parser previously emitted incomplete reports caught mid-write, ignored negative frame line numbers and silently navigated to a different frame, and failed to recognize non-ASCII filenames. Oversized line numbers could also throw and stop parsing.

Validation

  • ./gradlew.bat :core:test
  • ./gradlew.bat test
  • ./gradlew.bat buildPlugin
  • git diff --check

Closes #7

@janithcd
janithcd marked this pull request as ready for review July 30, 2026 12:39

@GabrielBBaldez GabrielBBaldez left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified: buildPlugin produces the zip, 7/7 in :core, and I ran the parser against the authoritative golden fixtures in the main repo —

full-report.txt  -> 1 report, culprit=OrderService.java:87
no-throwable.txt -> 1 report, culprit=null
rich-report.txt  -> 1 report, culprit=PaymentService.java:44

That middle line is the one I care about, and it composes with your #10: no-throwable now honestly reports no culprit instead of picking an unrelated frame, and the message you made reachable last time is what the user sees. Two PRs, one working behaviour.

The part that does the real work is markedFrameFound. Dropping the frame was the easy half; not falling back to frames.get(0) when a marked frame existed but was unusable is what stops the silent jump to the wrong file, and it's easy to miss that those are separate conditions.

Also noticed kts is ordered before kt in the alternation. That has to be that way — with kt first the engine matches .kt, needs :, finds s, and the whole frame fails. Your test covers it, so it can't silently regress.

Two notes:

The two parsers are deliberate twins and this lands the fix on one side. stacktale-vscode#5 is the same three bugs in TypeScript and is still open — the VS Code side still does if (!culprit && frames.length) culprit = frames[0] with no guard. If you want it, this implementation is the reference; if not I'll point whoever takes it here.

Whitespace: the blank lines between methods came out in both files, in the source and the test. I'll put them back on merge rather than send you round again.

Merging.

@GabrielBBaldez
GabrielBBaldez merged commit 3bbdd03 into stacktale:main Jul 30, 2026
@janithcd
janithcd deleted the fix/issue-7-parser-edge-cases branch July 30, 2026 16:43
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.

parser: truncated blocks are emitted, -1 line numbers navigate to the wrong file, unicode filenames are invisible

2 participants