Surface rename of the signed integer family: s1..s64 become i1..i64
(u1..u64, usize, isize unchanged). 'string' keeps the s-prefix arm in
name classification; width parsing moves to the i-prefix arm next to
isize.
Internal TypeId tags follow the surface (.s8/.s16/.s32/.s64 ->
.i8/.i16/.i32/.i64), as do mono-key mangle fragments (ptr_i64,
tu_i64_bool) and all display/diagnostic formatting (i{d}).
Migrated in the same sweep: stdlib + examples + issue repros + FFI C
companions (shared symbol names like ffi_id_i64), expected
stdout/stderr/ir snapshots, specs.md, readme.md, CLAUDE.md/AGENTS.md,
implementation_plan.md, docs/, issue writeups. Vendored stb_image and
historical flow state left untouched.
zig build test: 426/426; examples suite: 595/595.
3.5 KiB
0062 — generic function with a value-carrying ! return miscompiles
✅ RESOLVED (2026-06-01) — NOT A BUG (invalid repro syntax). The repro used the non-generic form
(T: type, …)/(T: Type, …)— a plain value param of typeType, NOT a generic type parameter. Perspecs.md(the$sigil introduces a generic type parameter), a function generic type param must be$T: Type. With the correct form, generic value-carrying failable composition (ERR E5.1 sub-feature 8) works fully:wrap :: ($T: Type, f: Closure() -> (T, !E)) -> (T, !E) { return try f(); } wrap(i32, closure(() -> (i32, !E) { return 7; })) catch e -1 // 7 r, err := wrap(i32, closure(() -> (i32, !E) { return 9; })) // r=9 wrap(i32, closure(() -> (i32, !E) { raise error.Bad; })) catch e -1 // -1The only real (separate, orthogonal) defect found: a NON-
$T: Typefunction param used as a type silently resolves to an empty{}(rendersT{}) instead of erroring — tracked as issue 0064, deferred (not ERR-scoped).
Symptom
A generic function whose return type is a value-carrying failable in the generic
type param — wrap :: (T: type, …) -> (T, !E) — does not substitute T in the
failable return tuple during monomorphization. Observed two ways:
- Consumed via
catch:LLVM verification failed: PHI node operands are not the same type as the result!— the success branch carries{}(an unsubstituted / empty value) while the handler branch carries the real success type. - Consumed via destructure: the success value renders as
T{}(the literal generic type name) instead of the concrete value, and the error slot is wrong.
Expected: T is bound to the concrete monomorphization type (i32), the success
value flows through as 7, and the error slot is 0 on success.
Reproduction
#import "modules/std.sx";
E :: error { Bad }
wrap :: (T: type, f: Closure() -> (T, !E)) -> (T, !E) { return try f(); }
main :: () -> i32 {
// catch form → LLVM phi type mismatch:
r := wrap(i32, closure(() -> (i32, !E) { return 7; })) catch e -1;
print("{}\n", r); // want 7
return 0;
}
Destructure form (same root cause, different surfacing):
r, err := wrap(i32, closure(() -> (i32, !E) { return 7; }));
print("{} {}\n", r, xx err); // prints "T{} i64"; want "7 0"
Investigation prompt
The bug is in monomorphizing a value-carrying failable return type in
src/ir/lower.zig. monomorphizeFunction (~10259) /
resolveReturnType2 (~8309) resolve the return type under type_bindings
($T → concrete). For a plain -> T this works; for -> (T, !E) the value
slot T of the failable tuple appears NOT to be substituted — the success
value stays the unsubstituted generic type (rendering as T{} / an empty {}
in IR), so lowerFailableSuccessReturn / extractSuccessValue and the try
success path produce a value of the wrong type, which the catch merge phi then
rejects.
Likely fix: ensure the failable-tuple return type is re-resolved through
type_bindings during monomorphization (the tuple's value fields, not just a
top-level $T), and that failableSuccessType / the try/catch success
extraction use the substituted tuple. Verify with both repros above (catch →
prints 7; destructure → prints "7 0"). This is ERR E5.1 sub-feature 8 (generic
functions with ! returns); the program-wide shape-union slice deliberately
excluded generic shapes pending this fix.