A.6.2.0b worker hit a real shared-`.next`-aliasing bug and stopped
per rule 7. Wwstage's N_TTUPLE chained element type ASTs via the
nodes' own `.next` field. `exprtype` routinely returns shared
nodes (sym.decl.lhs, struct field's `.lhs`, another N_TTUPLE's
`.list` element). Naive chain construction in the checker
corrupts source ASTs.
Introduce N_TPARAM = 67 as a chain wrapper for N_TTUPLE.list:
- `.lhs` holds the (possibly-shared) element type AST.
- `.next` chains within the parent N_TTUPLE.
- Other fields unused; never appears outside N_TTUPLE.list.
Mirrors cstage's Tparam at cmd/wcc/check.c:1437-1451. Cstage
keeps it at the Type layer; wwstage has no separate type layer
for tuple chains so the wrapper sits at the AST. Hare's design
intent at ref/hare/hare/ast/type.ha:117 uses `[]*_type` slice-of-
pointer — same principle, slice-flavored.
Migrations:
- lib/ww/ast.ww: kind + nkname + pr() unwrap (transparent for
the 990 -a astprint byte-diff).
- lib/ww/parse/parse.ww: parsetype N_TTUPLE construction wraps
each element in N_TPARAM (sole construction site).
- selfhost/cmd/wcc/check.ww: 4 readers (astalign, astsize,
tinfofornode TY_TUPLE, exprtype N_DOT-tuple-positional). The
last change retires the latent A.6.1.5b shared-`p` return.
- selfhost/cmd/wcc/cgenutil.ww: slotsize TY_TUPLE arm.
- selfhost/cmd/wcc/cgenexpr.ww: cgdot tuple-positional
(size/load op + str-check).
- selfhost/cmd/wcc/cgenstmt.ww: cglet TTUPLE init, cgmlet
call-return walk, cgforrange elem-size + bind-walk.
Out of scope: N_TFN params, N_TTAGGED variants, N_TSTRUCT fields.
N_TFIELD already wraps struct fields; N_TFN/N_TTAGGED aren't
currently chain-mutated by checker synthesis. If they ever are,
the same pattern applies.
Unblocks A.6.2.0b stamp on a clean foundation. Retires task #16.
Verified 132/132 incl. 990 AST byte-diff (astprint unwrap) + 995
self-rebuild byte-identity.
Hojun-Cho
805c841f34