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.

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.

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).