main is legitimately green, and the full wg-1.0 corpus has been failing for a long time. Both are true because no CI leg runs the corpus unfiltered.
Every wasm-spec invocation in .github/workflows/ci.yml is filtered:
zig build wasm-spec ... -Dwasm-spec-filter=linking
zig build wasm-spec ... -Dwasm-spec-filter=f32_bitwiseRun without a filter, the same runner reports:
pass=18778 fail=13 skip=479 crash=0None of the 13 live in linking or f32_bitwise, so no CI leg has ever observed them:
- #877 — 2 commands where we accept a malformed module (over-long LEB128). A real conformance gap.
- #878 — 10 commands rejected correctly but with non-spec diagnostic wording, from #296.
- #879 — 1 behavioral failure,
names.wast:630.
Suggested resolution
Add an unfiltered zig build wasm-spec leg, in Debug. Two reasons for Debug specifically:
- It is what the existing filtered legs already use (they pass no
-Doptimize). - Debug is the only mode where the executor's
appendAssumeCapacitycapacity asserts exist. While landing9ce52ff8I hit a build that aborted 48 times under Debug while ReleaseFast reported a clean 18,778 pass / 0 crash sweep of the identical binary — the asserts are compiled out, so every abort became a silent out-of-bounds heap write the corpus scored as a pass. A ReleaseFast corpus run cannot detect that class of defect at all.
Gating unfiltered would need #877–#879 fixed (or explicitly inventoried as known-failing with a shrinking budget) so the leg starts green. The 479 skips should also be reviewed against #486's "zero hidden skips" contract — they are mostly assert_malformed_text, i.e. .wat text parsing, which is outside the binary runtime by design, but that has not been re-confirmed recently.