T27.AI

Blog

A partial module needs its own verdict

2026-09-23 · 6 min read

JavaScript and TypeScript generation gained explicit omission records, so the Spec Explorer can distinguish a useful partial module from a complete one and from a failed compilation.

A generated module can be valid text and still be unusable. It can also be useful without being complete. Treating both cases as one red or green badge hides exactly the distinction a developer needs before importing the file. The recent JavaScript and TypeScript work in t27 made that distinction part of the compiler output, rather than leaving the website to guess.

The new backend exposed an old assumption

[proven] JavaScript joined the Spec Explorer in merged Trinity PR #1067; TypeScript followed in #1074. Upstream, t27 PR #4502 shared the value-emission machinery between the two targets instead of copying it. Escaping, reserved names and constant expressions therefore had one implementation. That is a useful design property, but shared code can share a defect just as efficiently as it shares a fix.

One such defect was a bare identifier that the generator printed without checking whether the emitted module could actually refer to it. The name might belong to a declaration that the backend had refused, occur later in the file before its value was available, or name a primitive type rather than a value. A comment described the reference as already declared. The comment was not a check.

[measured] The investigation reported in merged t27 PR #4529 used three different probes. A syntax check found duplicate exports. Importing every artifact found unbound identifiers that syntax checking could not see. Strict TypeScript checking found lost omission records and enum discriminants. These are different questions: whether a module parses, whether it loads, and whether its declarations describe usable values.

An omission becomes part of the result

The repair tracks emitted, refused and declared names separately. A reference is resolved against those sets instead of being printed optimistically. More importantly for a reader, a declaration that cannot be emitted is announced in a frozen __NOT_EMITTED__ list. The artifact can retain useful declarations without pretending that it contains the whole specification.

[proven] Merged Trinity PR #1084 carries this compiler into the website and reads the omission count from the compiler response. It does not search the generated source for a convenient string. The compiler already knows what it omitted; asking a second parser to reconstruct that knowledge would create another place for the answer to drift. The catalog records partialBackends: partial output prevents a fully working verdict, while a failed backend still takes priority over a warning.

There is a smaller accounting decision here worth keeping. The JS and TS omission counts are combined with a maximum rather than added together: the shared declaration omitted by both targets must not become two missing declarations in the catalog. This is a property of these paired backends, not a general theorem that a maximum deduplicates arbitrary sets.

What the published source snapshot actually counts

[measured] The manifest shipped by #1084 contains 1,419 specifications: 1,017 in the working category, 184 warnings and 218 failures. Seventy-one specifications are explicitly marked partial. Reading the manifest at the reviewed main revision confirms that 211 of the failures produce no AST; seven parse but lose one backend, six in verilog_hir and one in verilog. Those seven must not disappear inside a sentence claiming every remaining failure is a parser failure.

These are classifications of a particular corpus and compiler, not a performance score. The preceding website snapshot contained five fewer specifications, so the change in totals is not a clean experiment on an unchanged population. The upstream PR reports clean imports for its 1,205 emitted artifacts, but that result belongs to its 1,414-spec test corpus. It would be wrong to attach that denominator to the later website snapshot.

What this gives a consumer

The practical improvement is a third answer. Whole output, partial output and failed output now lead to different decisions. A consumer can inspect an omission list before trusting a generated module. A catalog can explain a warning instead of hiding incompleteness behind a success badge. The remaining parser and backend failures still need their own investigation; none of this establishes runtime correctness for every emitted program, hardware performance or complete language support.

For a team building code generators, the reusable test is simple: feed the product to the next real consumer, not only to its parser. Then make any accepted incompleteness explicit in the product itself. Syntax success is one receipt. It is not the final verdict.

Work with me

Want this kind of check on your own design?

I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.

Discuss your projectSee the verification service