Files
sx/issues/0062-generic-failable-return-not-monomorphized.md
agra 34bdf8b87c issues: file 0062 (generic failable return not monomorphized) + 0063 (free-fn UFCS pointer param by-value)
Both discovered while verifying ERR E5.1 "verify-only" sub-features against
the built compiler. 0062 is sub-feature 8 (generic + ! returns); 0063 is a
general UFCS/address-of miscompile orthogonal to ERR.
2026-06-01 22:13:12 +03:00

2.5 KiB

0062 — generic function with a value-carrying ! return miscompiles

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 (s32), 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 :: () -> s32 {
    // catch form → LLVM phi type mismatch:
    r := wrap(s32, closure(() -> (s32, !E) { return 7; })) catch e -1;
    print("{}\n", r);          // want 7
    return 0;
}

Destructure form (same root cause, different surfacing):

r, err := wrap(s32, closure(() -> (s32, !E) { return 7; }));
print("{} {}\n", r, xx err);   // prints "T{} s64"; 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.