sx/issues/0195-tuple-field-reflection-broken.md

Issue 0195 — field_count / field_name broken on tuple types (silent 0 + segfault)

RESOLVED. Fixed across both the lowering count switches and the LLVM backend. Root cause as diagnosed below: field_count/memberCount had no .tuple arm (silent 0), and the backend's field_name_get emission built a zero-length name array for any non-struct/enum kind while sizing its GEP at the real count → out-of-bounds GEP → segfault.

Scope broadened during adversarial review: the same defect was live for .array / .vector (field_count([4]i64) returned 4 but field_name([4]i64, 0) segfaulted — an exact clone). Rather than patch each kind in each of the (then three) parallel count switches, the backend was unified to derive BOTH the name-array build (getOrBuildFieldNameArray, src/backend/llvm/reflection.zig) AND the GEP sizing (emitFieldNameGet, src/backend/llvm/ops.zig) from the single source of truth TypeTable.memberCount / memberName — so the array length and the GEP type can never disagree again, for any kind. Members with no name (positional-tuple / array / vector elements) reflect as "" (one slot per member, always in-bounds); named-tuple elements recover their labels.

Fix sites: src/ir/lower/call.zig (field_count .tuple arm) · src/ir/types.zig (memberCount .tuple arm) · src/backend/llvm/reflection.zig + src/backend/llvm/ops.zig (unified to memberCount/memberName). The COMPILER-API VM readers (type_field_count / type_field_name, src/ir/comptime_vm.zig) ride the same memberCount/memberName and now report tuples correctly (positional type_field_name still fails loud via failMsg, not a crash). Delivered via the worker-fix override; adversarially reviewed (the review surfaced the array/vector clone). Regression: examples/comptime/0646-comptime-field-reflect-tuple-array.sx (struct / enum / positional + named tuple / array / vector). Full suite green.

Original writeup below.

---

Status: (historical — see RESOLVED banner). Hit while building race (the A1 async deliverable), whose comptime tuple→tagged-union synthesis must reflect the input named tuple's labels + element types. The reflection builtins are inconsistent across tuple types: field_type works, but field_count silently returns 0 and field_name segfaults.

Symptom

The comptime reflection #builtins (field_count / field_name / field_type, declared in library/modules/std/core.sx) behave correctly on structs/enums but are broken on tuple types — even though field_type's own doc (meta.sx) says it returns "the i-th field / variant-payload / element type", i.e. tuples are meant to be covered:

builtin	on struct {a:i64; b:bool}	on Tuple(i64, bool)	expected on tuple
field_count(T)	2 ✓	0 ✗ (silent wrong default)	2
field_type(T, i)	i64/bool ✓	i64/bool ✓	(correct)
field_name(T, i)	a/b ✓	SEGFAULT ✗	the label for a named tuple (a/b), or empty/null for a positional tuple

field_count returning 0 is the classic forbidden silent-default (CLAUDE.md "Silent unimplemented arms"): callers that trust the count then index out of range — which is almost certainly why field_name(tuple, 0) segfaults (it is reached with a count the caller believes is 0, or the field-name path itself lacks the tuple case).

Root cause (located)

field_type works because TypeTable.memberType has a .tuple arm (src/ir/types.zig:585 — .tuple => |t| if (i < t.fields.len) t.fields[i] else null).

field_count is broken because its lowering has a hardcoded switch with else => 0 and no .tuple arm:

// src/ir/lower/call.zig:2187-2200  (field_count(T) → const_int(N))
const count: i64 = switch (info) {
    .@"struct" => |s| @intCast(s.fields.len),
    .@"union" => |u| @intCast(u.fields.len),
    .tagged_union => |u| @intCast(u.fields.len),
    .@"enum" => |e| @intCast(e.variants.len),
    .array => |a| @intCast(a.length),
    .vector => |v| @intCast(v.length),
    else => 0,                       // ← tuple falls here → silently 0
};

TypeTable.memberCount (src/ir/types.zig:525-536) has the same gap — it lists struct / union / tagged_union / enum / array / vector then else => null, with no .tuple arm. (memberCount backs the abi(.compiler) type_field_count VM reader, so the COMPILER-API reflection path is silently wrong on tuples too, not just the #builtin.)

field_name lowering is at src/ir/lower/call.zig:2299 (emits a field_name_get instruction). memberName (src/ir/types.zig:561-569) DOES have a .tuple arm (returns t.names[i] if the tuple is named, else null), so the segfault is in the field_name_get runtime/emit path for tuples (or a downstream consequence of the bogus count) — to be confirmed during the fix.

Reproduction

#import "modules/std.sx";

main :: () -> i32 {
    // tuple field_count silently returns 0 (should be 2):
    print("tuple field_count = {}\n", field_count(Tuple(i64, bool)));   // prints 0

    // tuple field_type works fine:
    print("tuple field_type 0 = {}\n", type_name(field_type(Tuple(i64, bool), 0)));   // i64

    // tuple field_name SEGFAULTS (comment the line above out is not needed; this alone crashes):
    print("tuple field_name 0 = {}\n", field_name(Tuple(a: i64, b: bool), 0));   // SIGSEGV

    return 0;
}

Baseline (works): the same three builtins on S :: struct { a: i64; b: bool; } print 2, a/b, i64/bool correctly. type_info(Tuple(...)) also already reflects a tuple correctly (see examples/comptime/0623-comptime-metatype-tuple.sx), so the type table fully knows the tuple's elements — only field_count / field_name drop the tuple case.

Investigation prompt (ready to paste)

The comptime reflection builtins field_count / field_name are broken on tuple types: field_count(Tuple(i64, bool)) returns 0 instead of 2, and field_name(Tuple(a: i64, b: bool), 0) segfaults. field_type already works on tuples. Make field_count / field_name cover tuples the same way field_type does, including named-tuple labels.

Fixes, in order:

1. src/ir/lower/call.zig:2187-2200 (field_count lowering): the switch over the type info has else => 0 and no .tuple arm. Add .tuple => |t| @intCast(t.fields.len). (Replacing the else => 0 silent default with a loud else => @panic/diagnostic for genuinely-unsupported kinds would also surface the next such gap, per CLAUDE.md's anti-silent-default rule.)
2. src/ir/types.zig:525-536 (TypeTable.memberCount): same missing .tuple arm — add .tuple => |t| @intCast(t.fields.len). This backs type_field_count (the COMPILER-API VM reader), so it is silently 0 on tuples too. Verify with a comptime type_field_count probe.
3. field_name segfault: src/ir/lower/call.zig:2299 emits a field_name_get instruction; TypeTable.memberName (src/ir/types.zig:561-569) already handles tuples (named → label, else null). Find where the field_name_get path for a tuple faults — likely it indexes assuming a struct/enum layout, or is reached with the bogus 0 count from bug (1). A positional tuple has no names → decide the contract (return empty string ""? a diagnostic?) and make it not crash. A named tuple must return the label (a/b).

Verification: the reproduction above prints tuple field_count = 2, tuple field_type 0 = i64, tuple field_name 0 = a (named) — no segfault. Add a regression example under examples/comptime/ exercising field_count / field_name / field_type on both a positional and a named tuple. Then the blocked race synthesis (reflect a named tuple of task handles → mint a tagged-union with the tuple's labels as variant names) can proceed.

Why this blocks race

race((a: fa, b: fb)) must, at comptime, read the input named tuple's field labels (a, b) to name the synthesized RaceResult union's variants, and each element type to set the variant payloads. field_type already gives the types, but without a working field_count (how many arms) and field_name (the labels) the named-tuple synthesis cannot be written. The type-construction side (declare/define/make_enum) and struct/enum reflection are all proven working (examples/comptime/0619-0623); tuple field reflection is the one missing piece.