Standards conformance

Generated by zinc compat (tests/compat/run.mjs) on 2026-09-28 from Zinc ea4ef8c (with uncommitted compiler / runtime changes), darwin-arm64, in 924 s. Do not edit: rerun zinc compat. The raw per-test results are in tests/compat/results/2026-09-28.json.

Zinc runs every test four ways: the sim oracle (JavaScript on Node) and the native host build, each in the gradual profile (any is Dyn) and the strict one (any refused). Node, Deno, Bun and QuickJS run the same tests as reference engines, with the real harnesses (test262 assert.js, WPT testharness.js). Status letters: ✓ pass, ✗ fail (wrong result or crash), R rejected at compile time (a Z or TypeScript diagnostic: the program is outside Zinc’s subset or uses a missing API), U unsupported by the harness for Zinc (reflection helpers, the asynchronous testharness API, sloppy mode), T timeout. Rates are passes over every selected test, so R and U count as losses.

Engines: Zinc sim, Zinc sim strict, Zinc native, Zinc native strict, Node (v24.14.0), Deno (deno 2.9.6 (stable, release, aarch64-apple-darwin)), Bun (1.3.11), QuickJS (QuickJS version 2026-06-04). Suites: test262 7ab7fafa00 (BSD-3-Clause), wpt 375cf2548a (BSD-3-Clause), quickjs 2f0aa72a6b (MIT), plus 19 curated Node API tests (tests/compat/node).

Summary

305 selected test262 tests use features outside Zinc’s design (skipped on every engine, below).

1. WinterTC Minimum Common Web API

The primary axis: the 78 interfaces and globals of Ecma TC55’s Minimum Common Web API (2025 snapshot, ECMA-429), each with the WPT files that test it. Exposed is how the API reaches a Zinc program (a global declared in lib/zinc.d.ts, an import from a zinc: module, or nothing); the reference columns say whether globalThis has it (✓ / ✗) and the share of WPT subtests passed. Zinc cells count WPT files passed per profile (gradual · strict).

Why the WPT files do not pass on Zinc (sim, gradual):

2. ECMAScript (test262)

A deterministic sample of 2113 tests (every n-th file, tests/compat/manifest.json) from the built-ins Zinc implements and from the language directories. Zinc inputs get the mechanical rewrites zinc check --fix would make (var → let) and the harness passes error constructors by name; test262’s propertyHelper.js and friends need property descriptors and are U on Zinc.

Zinc outcomes:

Skipped test262 features

Outside Zinc by design (docs/guide/02-language.md: no reflection, no regex engine, no symbols beyond Symbol.iterator / Symbol.dispose, no typed arrays yet) or host-specific; skipped on every engine so the rates compare the same tests. Tests carrying several features count once per feature.

Reflect.construct 62 · Symbol 57 · BigInt 45 · Proxy 24 · Symbol.toPrimitive 20 · Symbol.species 17 · regexp-modifiers 13 · Array.fromAsync 10 · WeakMap 10 · cross-realm 9 · import.meta 8 · regexp-named-groups 8 · dynamic-import 7 · Reflect 6 · Symbol.matchAll 6 · Symbol.replace 5 · resizable-arraybuffer 4 · Symbol.match 4 · String.prototype.matchAll 4 · Symbol.unscopables 3 · Symbol.isConcatSpreadable 3 · WeakSet 3 · tail-call-optimization 3 · import-defer 3 · Symbol.asyncIterator 3 · Symbol.toStringTag 2 · Float16Array 2 · Symbol.search 2 · regexp-duplicate-named-groups 1 · Symbol.split 1 · source-phase-imports 1 · top-level-await 1 · module flag (harness runs scripts) 1

3. Node API (curated)

Self-contained tests after Node’s test/parallel for the Node-like APIs (fs, path, os, process, buffer, timers, events, util, crypto), with a trimmed common (mustCall). Zinc has its own modules (zinc:fs, zinc:sys, zinc:events…) but no node:* specifiers, so these measure source compatibility with Node programs.

4. QuickJS’s own tests

quickjs-ng’s tests/, one test per test_*() call (the function plus the declarations it reaches; qjs:os / qjs:std imports removed). The qjs binary here is Bellard’s QuickJS, so its misses on quickjs-ng-only features are expected.

5. Zinc failure clusters

Programs Zinc compiled but ran wrongly, grouped by the first error (all suites, all four Zinc runs). Each cluster names one test to reproduce with zinc compat --filter <id>.

Compile-time rejections (Zinc sim, gradual), by diagnostic:

Sim / native divergences

The sim is the oracle: a program must behave the same natively. 39 test(s) differ:

6. WinterTC compliance

What a claim needs (ECMA-429 §Conformance): every interface and global of section 1 exposed on globalThis with the behaviour of its W3C / WHATWG definition, conformance to ECMA-262, the global error / unhandledrejection / rejectionhandled events (on an EventTarget global or an equivalent mechanism), a navigator.userAgent token, and written documentation of every deviation with its impact.

Where Zinc stands. Zinc cannot claim WinterTC conformance, and running WPT verbatim is not how it could get there:

• Programs are typed ahead of time. WPT (and test262) files are dynamic JavaScript: untyped callbacks, mixed-type arrays, instanceof on constructors passed as values, property enumeration. Zinc’s strict subset rejects nearly all of them at compile time (the R column), whatever the API behind them does. A WinterTC profile for Zinc would be measured with typed ports of the WPT files, one per API, kept next to these runs.
• Web APIs are modules, not globals. globalThis is refused by design (Z1015) and there is no self; the Web APIs being written for Zinc (zinc:web: TextEncoder / TextDecoder, atob / btoa, URL / URLSearchParams, Event / EventTarget / CustomEvent, AbortController / AbortSignal, crypto) are imports. A conformance claim needs them as ambient globals (a lib/web.d.ts plus auto-import in the compiler).
• Typed arrays and ArrayBuffer are missing (Zinc uses u8[]). Almost every binary API depends on them: TextEncoder, crypto.getRandomValues, Blob / File, streams chunks, fetch bodies, compression, WebAssembly.
• No reflection. WebIDL behaviour (property descriptors, length / name of methods, prototype chains, Symbol.toStringTag) is checked by most WPT files and by test262’s propertyHelper.js.

Gaps, by effort (S: days, M: 1-3 weeks, L: a quarter or more, one engineer):

7. Fixes made with this harness

The first run of this harness found these; each has a regression program in tests/conformance (sim and native print the same bytes, checked against Node too). Together they move the test262 sample from 16.7% to 20.5% on the sim and from 14.4% to 19.0% natively, and cut the sim / native divergences from 51 tests to 35.

8. Larger gaps found (ECMAScript)

Ordered by the number of selected tests they cost (see the clusters above). Effort as in section 6.

The Web API branch. zinc compat --zinc <checkout> measured a snapshot of the parity branch (zinc:web, commit e0f0e8c): 2 of the 222 WPT files pass on the sim (url-tojson, urlsearchparams-stringifier); the others are rejected for the reasons of section 6 (globals, typed arrays, dynamic test code), and two crashed the compiler with the stack overflow fixed here.

How to run

zinc compat                                  # all suites, 4 jobs; writes tests/compat/results/<date>.json and this page
zinc compat --suite wpt --engines zinc-sim,node
zinc compat --filter built-ins/String/prototype/trim   # a slice (recorded in tests/compat/cache/last.json only)
zinc compat --zinc path/to/other/checkout    # measure another Zinc tree (a branch), same tests
zinc compat --check                          # exit 1 if a Zinc pass recorded in tests/compat/baseline.json regressed
zinc compat --update-baseline                # after an intended change
zinc compat --report tests/compat/results/<date>.json   # regenerate this page

The harness is tests/compat/run.mjs (selection, engines, classification) and report.mjs (this page); the pins and the WinterTC API list are in tests/compat/manifest.json, the Zinc harness shims in tests/compat/shims, the Node API tests in tests/compat/node, and these notes in tests/compat/notes.md.

Edit this page on GitHub ↗