Commit Graph

3 Commits

Author SHA1 Message Date
ce3a25a0b4 test: contain sepwork scratch per-driver tmpdir, fix /tmp+in-repo leak (#8)
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.
2026-06-22 23:29:39 +09:00
e8ef1e061c test: require diagnostic on reject rows, close crash-vacuity (#20)
Reject helpers checked only rc!=0, so a SEGFAULT (exit 139, or the
driver's "w6c failed" exit 1) counted as a clean reject -- a wwstage
crash could pass vacuously (it did, latently, on bodied bare-... pre
#11). Every reject row now captures stderr and requires the actual
diagnostic substring (rc!=0 AND strstr) across all 16 reject tests; a
crash emits no diagnostic, so it now fails. This is the
differential-reject backstop (#15): both stages must cleanly reject
with the expected message.

Two genuine cstage/wwstage diagnostic-body divergences are documented
inline via per-stage substrings, not papered over (845 tuple parse,
catA_f2 tuple arity); catalogued in #21.
2026-06-21 13:04:59 +09:00
6b7de54272 wcc/ww: reject (a,) single-element trailing-comma tuple (catB-92)
wwstage's tuple-parse loop checked the RPAREN-break at the top, so
`(a,)` parsed as a 1-element N_TUPLE and reached cgen — a silent
wrong-accept. A trailing comma is legal only after >=2 elements.
Align the loop order to cstage cmd/wcc/parse.c:552-558 (parse each
element before the RPAREN-break); `(a,)` now errors at the next
parseexpr, `(a, b)` / `(a, b,)` are unchanged. cstage already
rejected; this brings wwstage's w6c_ww parser into agreement.

Regen w6c/wwdump combined.ww (parser embeds in both). Valid-program
codegen unchanged → cs==ww byte-id gate stays green.
2026-06-15 03:49:38 +09:00