You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Close the last 2 valid-code conformance gaps → 100% valid-code coverage
Both remaining REAL gaps (valid TS that tsc parses cleanly but we failed)
are fixed. Valid single-file coverage is now 3376/3376 (zero gaps);
bidirectional agreement with tsc is 96.7% (the rest is over-acceptance).
1. Postfix closes the access tail (parserComputedPropertyName29).
`[e] = id++` ⏎ `[e2]` was mis-parsed as `(id++)[e2]`, but member access
can't attach to a postfix result (an UpdateExpression isn't a
MemberExpression). After a true postfix binds, no access-tail LED
(`.`/`[`/`(`/`?.`/`<T>`/tagged-template) may follow — binary/ternary
ops still do. Tails are detected structurally (last item isn't a
self-operand; connector isn't a word-keyword), so the engine stays
language-agnostic. TS non-null `!` moves from prec-postfix to an
access-tail LED `[$, '!']`, since it IS part of the LHS chain
(`x!.y`, `x!()` are valid). Bonus: `a--.x`, `a++ ++`, `foo ++ ++` are
now correctly rejected (they were over-accepts).
2. Mixfix operand re-bind for left-recursive rules (inferTypesWithExtends1).
`(T extends infer U extends number ? 1 : 0)` failed: inside parens, an
`infer …extends T` over-consumed the conditional's `?`. The re-bind that
already fixed this for expressions lived only in parsePratt, but Type is
left-recursive (parseLeftRec). Factor the mixfix detection into mixfixOf()
and reuse matchMixfixLed from parseLeftRec via a contMixfix map.
Add test/conformance-matrix.ts (the bidirectional confusion matrix vs tsc's
parseDiagnostics — the real metric) and test/verify-rejects.ts (checks we
reject at tsc's first-error offset). Regenerate artifacts; reframe the
README around valid-code coverage + bidirectional agreement.
Copy file name to clipboardExpand all lines: README.md
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ A TextMate grammar is a pile of regexes guessing at a language's structure. It's
10
10
11
11
Monogram inverts the dependency:
12
12
13
-
1.**Write the grammar, then prove it.** The grammar is executable. Monogram runs it as a recursive-descent + Pratt parser over the TypeScript conformance suite. Today it parses **95.4%** (3602 / 3776 files); the goal is **100% coverage of the official parser** — at which point the grammar is a *verified, complete model* of the language's syntax, not an approximation.
13
+
1.**Write the grammar, then prove it.** The grammar is executable. Monogram runs it as a recursive-descent + Pratt parser over the TypeScript conformance suite and measures conformance *bidirectionally* — it must accept what `tsc` accepts **and** reject what `tsc` rejects. Today it parses **100% of valid single-file cases** (3376 / 3376 — zero valid-code gaps) and agrees with `tsc`**bidirectionally on 96.7%** (3544 / 3664); the remaining gap is *over-acceptance* (the grammar is still too permissive on some invalid inputs), and the goal is 100% both ways — a *verified, complete model* of the language's syntax, not an approximation.
14
14
15
15
2.**Derive the highlighter from the proven grammar.** The TextMate grammar is generated from that same parser-validated grammar — never hand-written. Its correctness is underwritten by the parser conformance run, not by regex tuning.
16
16
@@ -37,7 +37,8 @@ And — from the same grammar — first-pass generators for the rest of the edit
37
37
Validated on TypeScript (grammar: [`examples/typescript.ts`](examples/typescript.ts), 537 lines):
38
38
39
39
```
40
-
Parser conformance 95.4% 3602 / 3776 files from the TypeScript conformance suite (goal: 100%)
0 commit comments