From 34bdf8b87cf2ca3de9474eb2cdd20fad76b1a947 Mon Sep 17 00:00:00 2001 From: agra Date: Mon, 1 Jun 2026 22:13:12 +0300 Subject: [PATCH] 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. --- ...neric-failable-return-not-monomorphized.md | 58 +++++++++++++++++++ ...e-fn-ufcs-pointer-param-passes-by-value.md | 52 +++++++++++++++++ 2 files changed, 110 insertions(+) create mode 100644 issues/0062-generic-failable-return-not-monomorphized.md create mode 100644 issues/0063-free-fn-ufcs-pointer-param-passes-by-value.md diff --git a/issues/0062-generic-failable-return-not-monomorphized.md b/issues/0062-generic-failable-return-not-monomorphized.md new file mode 100644 index 0000000..6cc4fe3 --- /dev/null +++ b/issues/0062-generic-failable-return-not-monomorphized.md @@ -0,0 +1,58 @@ +# 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 + +```sx +#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): + +```sx +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](../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. diff --git a/issues/0063-free-fn-ufcs-pointer-param-passes-by-value.md b/issues/0063-free-fn-ufcs-pointer-param-passes-by-value.md new file mode 100644 index 0000000..060c53a --- /dev/null +++ b/issues/0063-free-fn-ufcs-pointer-param-passes-by-value.md @@ -0,0 +1,52 @@ +# 0063 — free-function UFCS with a pointer first-param passes the struct by value + +## Symptom + +Calling a **free** function via UFCS where the function's first parameter is a +pointer (`p: *Parser`), on a local struct value, passes the struct BY VALUE +where the function expects a pointer: + +``` +LLVM verification failed: Call parameter type does not match function signature! + %load = load { i32, i32 }, ptr %alloca, align 4 + %call = call i32 @bump(ptr @__sx_default_context, { i32, i32 } %load) +``` + +The UFCS auto-address-of (`p.bump()` → `bump(@p)`) does not kick in for free +functions; the receiver is loaded by value instead of having its address taken. +The same method defined **inside** the struct works fine — so this is specific +to free-function UFCS, not method calls in general. Not failable-specific (the +repro is a plain `-> s32`), so this is orthogonal to ERR. + +Expected: `p.bump()` on a `*Parser`-first-param free function takes `@p`'s +address, matching the in-struct method behavior. + +## Reproduction + +```sx +#import "modules/std.sx"; +Parser :: struct { pos: s32; } +bump :: (p: *Parser) -> s32 { p.pos += 1; return p.pos; } // FREE fn, pointer first param + +main :: () -> s32 { + p := Parser.{ pos = 0 }; + print("{}\n", p.bump()); // LLVM signature mismatch + return 0; +} +``` + +Control (works): move `bump` inside `Parser :: struct { … bump :: (p: *Parser) -> s32 { … } }`. +Also fails with an explicit `bump(@p)` — so the explicit address-of of a local +struct into a pointer param is the underlying miscompile, not just the UFCS sugar. + +## Investigation prompt + +Two related call paths in [src/ir/lower.zig](../src/ir/lower.zig): (1) UFCS +rewrite of `obj.fn(args)` for a free function whose first param is a pointer — +it must auto-take-address of the receiver (as the in-struct method path does); +(2) more fundamentally, lowering an explicit `@local_struct` argument into a +`*T` parameter loads the struct by value instead of passing its slot pointer. +Compare the in-struct method call lowering (which marshals the `self`/receiver +correctly) against the free-function call + the address-of-local lowering. +Verify with the repro (`p.bump()` and `bump(@p)` both compile + print 1, then 2 +if called twice).