The wcc test drivers ran `ww build <bare-/tmp src>` with no -o, so the
compiler's <stem>.sepwork scratch landed beside the source and was never
cleaned: unbounded /tmp growth (2195 stale dirs observed) that fills tmpfs
and fabricates phantom test failures + silent harness aborts, and for
in-repo fixture builds leaked .sepwork into the tracked tree.
Each leaking build now writes its source + output inside a per-invocation
tmpdir, passes -o <tmpdir>/<stem> so the .sepwork lands inside it, and
rm -rf's the tmpdir on every exit path -- including fopen-fail and the
expected-fail reject builds (scratch is mkdir'd before the build can fail).
`ww run` and explicit-`-o`/byte-id helpers are left as-is; the 990/993
byte-id comparison logic is byte-for-byte unchanged.
Two items filed separately (this commit holds the no-Makefile / no-main.c
rail):
- #13: a stale <src>.s byte-id readback (749) silently no-ops since
separate-compile emits .s to <ostem>.sepwork/__root.s; documented inline.
- #14: build-system Makefile recipes build selfhost/cmd/*/main.ww with no
-o and leak main.sepwork in-tree (bounded, gitignored; own commit).
One concern -- sepwork leak hygiene -- across 228 drivers; uniform
transform applied per-file and two-round reviewed. make test: all 402
passed, zero net-new /tmp scratch, zero test-driven in-repo .sepwork.
Drop the `!TY_ARRAY` exclusion in the bare-let no-rhs zero-fill (cgen.c
N_LET else + cgenstmt.ww cglet, both gated `sz>8 && !TY_ARRAY`) so an
uninit `[N]T` array local zero-fills like every other composite (Go-zero
per user ruling). The zero-fill extent is the array's chased ABI size
(lu->size / chased tinfo.size, rule-13 — never a hardcoded count*esz),
NOT the slot-padded letslotsize, so a non-8-multiple array ([20]u8 = 20)
zeroes its exact bytes instead of over-zeroing to the 24B slot. The
unrolled MOVQ/MOVL/MOVB run mirrors the existing composite path; the
largest real local array ([256]u8) is 32 MOVQs (pathbuf[4096] is a
module GLOBAL, BSS-filled — never on this stack path, so no large-fill
case exists).
Closes a gate-blind #263-class bug: `let a: [3]int;` (no init) read
whatever the stack held — a clean frame masked it (fresh stack = 0), a
dirtied frame exposed it (d_array=165 garbage). BOTH stages emitted no
fill, both-wrong-IDENTICAL, so the cs==ww byte-id net could not see it.
The load-bearing net is therefore a RUNTIME dirtied-stack zero-read
(944_array_zeroinit_run: array-elem / narrow [4]u32 / non-8-mult [20]u8
/ 2D + an initialized control), not asm presence.
Deliberate byte-id EVENT: every uninit-array source site gains zero-fill
insns, so the 990-997 .s MOVE vs the prior tree; cs==ww HOLDS (both add
the identical insns). The 990-997 byte-id + 995 self-rebuild staying
GREEN is the fixpoint proof — it proves every uninit compiler-array is
write-before-read, so the zero-fill is purely additive and the
ww1->ww2->ww3 self-rebuild fixpoint holds by construction. w6c/wwdump
main.combined.ww regenerated (cgenstmt.ww embeds there).
#84 is ARRAY-ONLY; the no-default reject-set (uninit tagged / plain-*T)
is split to #113, parked behind a ruling — selfhost relies on the
current (void|T) zero-fill (the "not-set-yet" idiom).
