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.
Row 5 in 098b58d was byte-identical to row 2 ({i32,i32,i64} fields
{{4,4},{4,4},{8,8}}): same struct, same field table, only label
differed. The row's own comment acknowledged "off from 8→8 (already
aligned)" — i.e., it did not exercise mid-record alignment at all
despite the label "i32_i32_i64_mid_align" and the commit-body
listing "mid-record align step explicit".
Replace with {i16, i64}: after f1 off=2, f2 must align off 2→8
before placing the i64. A missing `off = align(off, fa)` on either
walker (check.c:760 / check.ww:958 / structabisize) would land f2
at off=2 and size to 10 — clearly red. This is the shape the row
was meant to be.
Six distinct shapes after this fix; gate polarity unchanged (GREEN).
Project #78 was ken-flagged: cstage folded size(struct{i32,i32,i32}) to
12 (cmd/wcc/check.c:760, `(off + maxalign - 1) & ~(maxalign - 1)`) while
wwstage walked a slot-padded fsz ladder and yielded 16. The two
checkers ran different layout formulas. d4e500f (#169) closed the
cgen ABI half by introducing structabisize and walking it via per-
field tinfo.align; 39f9267 + 66a91c8 converged the remaining cgen
sites that had picked the slot-padded number. Verified at the size(T)
fold and the .s byte-id on every layout-edge shape.
Add 762_struct_abi_size.c (6 table rows) to lock the closure. Each
row carries a (sz, aln) field table; the expected size is computed in
C via the Hare layout formula (rule 13: no hardcoded size literals —
a formula bump lands in compute_expected and every row tracks). Both
gates run per row: a runtime check that `return size(T): i32` matches
the computed expected on both stages (catches a fold drift), and a
w6c vs w6c_ww .s byte-id (catches a cgen-ABI walker drift even when
the fold still matches — the two walkers are independent SSoTs).
Rows target maxalign edges:
i32_x3_maxalign4 #78 canonical, natural==ABI==12
i32_i32_i64_lead_narrow maxalign 8, narrow lead, ABI 16
i64_i32_i32_sub8_tail #169 sub-8 tail, ABI 16 (the round-up)
i16_x3_maxalign2 maxalign 2, natural==ABI==6
i32_i32_i64_mid_align mid-record align step explicit
i64_x3_natural_24 all 8-wide, natural==ABI==24
GATE POLARITY: this file must stay GREEN. A red here means either
d4e500f reverted, or one of the two layout walkers (check.c:760 /
check.ww:958 / cgen.c struct_arg_size / cgenutil.ww structabisize)
drifted from the formula.
