sx/issues/0063-free-fn-ufcs-pointer-param-passes-by-value.md

0063 — free-function UFCS with a pointer first-param passes the struct by value

✅ RESOLVED (2026-06-01). The free-function UFCS fallback in src/ir/lower.zig ("Try to resolve as bare function name") built method_args with the value receiver but never called fixupMethodReceiver, and never lazily lowered the target — so the receiver was passed by value (LLVM signature mismatch) and a UFCS-only function was declared but never emitted (link error). Fix: that path now (1) lazily lowers fa.field if it's a known fn not yet lowered, and (2) calls fixupMethodReceiver + coerceCallArgs exactly like the qualified-method path. The explicit bump(@p) form was always fine. Regression: examples/0039-basic-free-fn-ufcs-pointer-receiver.sx.

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 -> i32), 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

#import "modules/std.sx";
Parser :: struct { pos: i32; }
bump :: (p: *Parser) -> i32 { p.pos += 1; return p.pos; }   // FREE fn, pointer first param

main :: () -> i32 {
    p := Parser.{ pos = 0 };
    print("{}\n", p.bump());   // LLVM signature mismatch
    return 0;
}

Control (works): move bump inside Parser :: struct { … bump :: (p: *Parser) -> i32 { … } }. 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: (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).