v4.5 phases 98-105: parser conformance, live compiler diagnostics, one set of errors, live diagnostics on large workspaces, and the exit measurement

[StephanWald]

Lands phases 98–105 of the v4.5 Compiler Conformance milestone. Local main did not
receive phases 98–101, so this branch carries all of them: source, tests, and planning
artifacts for every phase below (the endpoint work itself lands in the separate bbj-ls
repository; only its planning artifacts appear here).

What's in it

Phase	What it does
98	Line-break and validation false alarms (A2) — TABLE/RESTORE lexer work, validation fixes
99	Parser gaps, the largest groups — grammar and lexer
100	Parser gaps, remaining groups, long tail and examples
101	parseProgram endpoint — lands in the separate bbj-ls repo, so only its planning artifacts appear here
102	Live compiler diagnostics with older-BBj fallback
103	One set of errors — reconciling the live parser's diagnostics with the language server's own (the feature below)
104	Conformance measurement and milestone exit (the exit numbers below)
105	Live diagnostics responsiveness on large workspaces (the feature below)

Phase 102 — live compiler diagnostics

The text in an open .bbj buffer, unsaved edits included, is sent to BBj's own parser through
the existing localhost interop socket 500 ms after the last edit, and the parser's errors come
back as Error-severity diagnostics without a save. They carry their own diagnostic source
(BBj Parser) so the existing BBjCPL-suppresses-Langium-parse-errors rule cannot absorb them.

Backward compatibility is decided by probing, not by version strings: the first call to a
bbj-ls that lacks the method returns MethodNotFound, the service latches off for that
connection, and everything behaves exactly as 0.16.x did. The latch is keyed to the connection,
so a reconnect re-probes in either direction.

Coordinate conversion is pinned against colon-continuation statements, user-written line
numbers, CRLF, and a last line with no trailing newline. Out-of-range lines clamp rather than
drop, and collapsed or inverted ranges span the whole line. The convention is confirmed once
against the real deployed endpoint by a RUN_BBJ_TESTS-gated test, which skips rather than
fails when BBjServices is unreachable, so CI stays hermetic.

Both extensions' guides now state that live compiler diagnostics need BBj 26.03 or later, with
BBj 25.00 unchanged as the base prerequisite. No new setting and no new IDE surface were added.

Both phase 102 hand-verifications have since passed

Both walkthroughs described above — the compiler's syntax errors appearing while typing in both
IDEs, and the fallback behaviour against an older BBj — were observed and confirmed by hand on
2026-09-22. One caveat was noted and is tracked separately: on a large workspace nothing live
appears until the initial whole-workspace build finishes, a pre-existing scheduling gap this
phase exposed rather than caused; see issue #692, addressed by a later phase in this milestone.

Phase 103 — one set of errors

With live compiler diagnostics on, BBj's own parser is the authority on syntax: a line that both
the compiler's parser and the language server's own lexer or parser would reject now shows
exactly one diagnostic — the compiler's own message, from the live parser. The language server's
own lexer, parser and line-break complaints on a line the compiler accepts stay visible, but
downgraded to a warning, and they never flash back to red while a verdict from the compiler is
outstanding — only the next verdict can change them again. The save-time compiler run no longer
duplicates work while the live parser is answering: it is skipped whenever the current text
already has a fresh verdict, and it still runs exactly as before whenever a parse attempt fails,
the connection drops, or an older BBj without the endpoint is in use — merging its result onto
the language server's own diagnostic exactly as 0.16.x did. Against an older BBj, both extensions
are untouched by this phase's changes.

Two hand-verification runbooks are staged for this phase and will be run before merge, covering
both states of the server: with the endpoint answering (one diagnostic per rejected line, no red
flashes on an accepted line, the save-time run skipped while a verdict is fresh) and with a
pre-endpoint jar swapped in (the compiler's own save-time diagnostics restored, nothing from the
live parser, and the same old behaviour throughout).

Phase 104 — exit measurement

The milestone's own baseline, measured against a corpus of 11,898 compiler-accepted and 1,210
compiler-rejected BBj programs: the language server alone rejected 168 of the valid programs and
raised a validation error on a further 267, while missing 658 of the invalid ones outright.

Measured the same way at the milestone's close, with BBj's own parser verdict now feeding the
language server's live diagnostics: the language server alone still rejects 9 of the valid
programs and raises a validation error on 22 more — both essentially unchanged from partway
through the milestone, since no parser or validation work landed after that point — while, once
the compiler's own verdict is applied, only 31 of the 1,210 invalid programs are still missed, a
little over 2.5%. Every one of the 13,108 calls this measurement made to the live parser
succeeded; none failed or timed out.

The private conformance harness that produces these numbers gained a mode that calls the real,
deployed BBj parser for every file in the corpus rather than relying on the language server's own
parser alone. It stays local and is never run in CI; the corpus itself never enters this
repository. A short pointer document next to this repository's own small, synthetic regression
fixtures explains where the harness lives and how a maintainer would re-run it.

The residual invalid programs the live parser still misses are, without exception, ones whose
defect is semantic — an undefined label or function and the like — rather than a syntax error;
the live parser only ever reports syntax, so this is expected and by design, not a parser gap.
Those cases stay the responsibility of the save-time compiler run this project already ships,
which has always checked semantics as well as syntax.

The whole-suite test gate was re-confirmed on the final tree in every mode this project runs it:
the bbj-vscode suite with BBjServices reachable, the same suite the way this repository's CI
runs it (BBjServices unreachable), and the IntelliJ suite. Both distributables — the VS Code
extension and the IntelliJ plugin — were rebuilt from the final tree, with the plugin's bundled
language server confirmed identical to the one just built.

Phase 105 — live diagnostics responsiveness on large workspaces

Live compiler diagnostics now appear while the initial build of a large workspace is still
running, in both VS Code and IntelliJ. Previously the live parse only started once Langium's own
workspace build lock was free, so on a workspace large enough for the initial build to take a
while, nothing from the live parser showed up until that build finished. The live parse is now
armed directly from document open and change events instead of waiting on that lock, and it
travels over its own dedicated interop connection to the server, falling back silently to the
shared connection if a second one can't be opened.

Measured on a real large workspace, with three timed samples per cell: VS Code's median wait for
the first parser diagnostic on an invalid line typed during the initial build dropped from
58.9 s to 5.3 s; IntelliJ's dropped from 66 s to 6 s. Full method, environment and per-sample
numbers are in the phase's measurement record.

Issue #692 stays open until this pull request merges.

One server-side note carried from phase 105's measurement: a parser cache-isolation fix in the
separate bbj-ls repository must still reach the release branch that ships as BBj 26.03 before
this improvement is fully in users' hands.

Verification

• Whole suite: green on the final tree, with every failing test name also failing on the phase
  base — the documented local interop-backend drift, unchanged across every wave gate from phase
  98 through phase 105
• Live-endpoint confirmation tests pass against the deployed endpoint, including a direct check
  that the shipped reconciliation agrees with the real compiler on both a jointly-rejected line
  and a compiler-accepted document
• The milestone's own exit measurement (phase 104, above) passed every one of its numeric targets
• Register check over the full branch diff: clean (no internal planning identifier reached a
  shipped file)
• Commit bodies scanned for a closing keyword: clean — this repository squash-merges and
  concatenates every commit body, so a stray closing keyword in any one of them would close an
  unrelated issue early
• Both distributables (VS Code extension and IntelliJ plugin) were rebuilt from the final tree
  and hand-verified for phases 102, 103 and 105, and rebuilt again for phase 104's measurement

Holding this pull request open

The milestone's phases are now complete. Merging this pull request and completing the milestone
stay with the maintainer.

🤖 Generated with Claude Code