A wasm32 build says ok: for a module that cannot execute one instruction

Found 2026-09-19 by frankb-56 while measuring the wasm32 walls for bug-c-hosted-c-on-wasm32-needs-environ-and-va-arg-.... It deliberately did not change it, calling it a topic collision rather than a doubt: the floor belongs to the wasm backend and so does the policy.

Why this is the expensive class and not a cosmetic exit code

It is the silent-negative shape this repo keeps paying for: the compiler answers correctly about what it emitted and says nothing about whether it can run. Same family as the xtensa signal stub that compiled, installed, returned 0 and dropped every delivery (92d2967ad), and as the full-disk short write that printed ok: with exact byte counts for a truncated binary. Every cheap instrument passes: the module is valid, the writer succeeded, rc=0.

The fork, and why it is not a one-liner

unreachable as a partial-lowering floor is right — it keeps the backend landing incrementally instead of on a branch. The question is only what the DRIVER should report when the floor is reached in the entry point.

The obvious rule — fatal when the entry traps — reds the one test that exists to document the mechanism, because that test's unreachable body IS main$0. Any fix has to separate "a gap the author intended to demonstrate" from "a gap that silently shipped", and nothing in the emitter records intent today.

Measured population, so nobody re-derives it

RE-MEASURED 2026-09-19 (frankB), and the claim HOLDS — but read the population line before quoting either number.

The load-bearing half is re-confirmed at HEAD. The single gap is test/test_wasm32_two_gaps_in_one_body.pas — the documentation test — and its unreachable body is main$0:

wasm32: 139 of 140 bodies lowered; 1 emitted as `unreachable`; 2 distinct gap(s) seen
    main$0 — string operand of type Pointer
        and also — `=` on strings

So a naive "fatal when the entry traps" rule still reds exactly this test and nothing else. That argument is unchanged and is the reason this is filed rather than fixed.

WHY THE TWO ROWS DO NOT RECONCILE, AND IT IS NOT A CHANGE IN THE TREE. The original number cannot be reproduced, because the ticket recorded the COUNT and not the SET. 61 is not reachable from any definition I can construct: the .pas population is 43, adding .npy and .c reaches 47, and test/wasm/* is 98 once the shell scripts are counted. The original census presumably reached sources outside test/, and nothing here says which — so its "1 unrelated failure" has no denominator anyone can re-derive either.

Both numbers are true of what they measured, and neither may be quoted without its population. The re-run's is one line above and the tool prints its own denominator on every run for exactly this reason (see its header: a rate needs its denominator printed beside it, every time).

What would retire this table: the wasm32 population changing — a new test/wasm/*.pas, or the documentation test being renamed or removed. Re-run tools/wasm32_gap_census.sh <out> <list> and replace the second row with its own sha; do not edit the first, which is a record of a different measurement.

Not to be confused with

bug-wasm-hosted-compiler-crashes-node-but-not-wasmtime-on-a-full-compile — that is a runtime disagreement between hosts. This is the build reporting success for something no host can run.