83025b03a635339c69658f8f5fe08bbfa71d058f
type pair = (int, int); let x: pair = (3, 4) -- an alias of a tuple initialized from an untyped literal, and passing such a value to a fn -- was a both-stage bug, mirror-twins of the same TY_NAMED-not-chased root: cstage CHECKER over-rejected the init (not assignable to declared pair): type.c's tuple-assignable arm gated on the un-chased dst kind, so a TY_NAMED alias skipped the per-element untyped->int coercion the direct tuple path applies. Fix: chase TY_NAMED both sides (mirrors the #258 slice-borrow arm). Direct and typed-alias tuples already worked; only alias+untyped was rejected. wwstage CGEN dropped the second word of an alias-tuple fn-arg: the tuple-param spill at cgendecl.ww gated on the syntactic N_TTUPLE, so an alias param (N_TNAME) fell to the scalar path and spilled one slot -> t.1 read frame garbage. Fix: chase the alias via aliaslookup to the resolved N_TTUPLE and spill all its slots. cstage cgen was already correct -- the bug was checker-only there. Converges cs==ww byte-id. One commit: same construct, the two halves must ship together (either alone leaves cs!=ww). test/wcc/826 (init/fn-arg/return, 2-field byte-id); test/wcc/944 4 rows graduated err->run-correct. byte-id 990-997 8/8.
Description
No description provided
Languages
C
89.4%
Python
7.2%
Makefile
2.3%
Shell
0.8%
Assembly
0.3%