sx/issues/0186-closure-optional-param-arg-coercion.md

0186 — calling a closure VALUE with a ?T parameter does not coerce the argument

RESOLVED. Root cause as diagnosed below: the closure-VALUE call path in src/ir/lower/call.zig lowered args without coercing to the closure's declared parameter types. Two-part fix: (1) resolveCallParamTypes now returns the closure/function value's param types for an identifier callee bound to a closure/fn VALUE in scope (so args lower with the right target_type; precedes function-name resolution since a local value shadows a function); (2) new free fn coerceClosureCallArgs coerces each already-lowered user arg to the closure's param type via coerceToType, applied at all three call_closure emission sites (local-variable callee, struct-field callee, force-unwrap/expr callee) AND the local function-pointer call_indirect path (which had the identical gap — an adversarial review flagged that the .function branch of (1) typed fn-ptr args but never coerced them). Now a concrete arg wraps present, null → absent — matching a top-level fn call, for both closure values and fn-pointer values. Regression: examples/closures/0312-closure-optional-param-arg-coercion.sx (local + struct-field closure + fn-pointer value, concrete + null args).

Discovered while verifying (separate, NOT fixed here): a lambda with an INFERRED return type (no -> T) and a block body with early returns mis-infers its return type (LLVM verifier failure) even with no optionals. Filed as issue 0187. (The 0312 regression uses an explicit -> i64 to avoid it.)

Symptom

When a closure value/variable (a :=-bound lambda, or any closure passed as a value) has a parameter of optional type ?T, the call site does NOT coerce the argument to ?T:

• A concrete argument (pick(7)) is NOT wrapped to a present ?i64 — inside the body the param reads as ABSENT (p == null is true), so the closure silently returns the wrong branch.
• A null argument (pick(null)) lowers null as a bare ptr null against a {i64, i1} parameter, which fails LLVM verification: Call parameter type does not match function signature! ptr null { i64, i1 }.

The SAME signature/body as a TOP-LEVEL function works correctly (e.g. issue 0900's guard), so the bug is specific to the closure-VALUE call path (src/ir/lower/call.zig's closure/fn-pointer call lowering), not optionals or flow narrowing. Found during the adversarial review of issues 0179 / 0185.

Reproduction

#import "modules/std.sx";
norm :: (p: ?i64) -> i64 { if p == null { return -1; } return 99; }
main :: () {
  pick := (p: ?i64) -> i64 => {
    if p == null { return -1; }
    return 99;
  };
  print("pick 7: {}\n", pick(7));   // prints -1 (WRONG — should be 99; arg arrives absent)
  print("norm 7: {}\n", norm(7));   // prints 99 (top-level fn, correct)
  // print("pick null: {}\n", pick(null));  // LLVM verifier failure: ptr null vs {i64,i1}
}

Expected: pick(7) prints 99 (the 7 wraps to a present ?i64), and pick(null) compiles (the null lowers to an absent ?i64), matching the top-level norm.

Root cause (hypothesis)

The closure-value call path in src/ir/lower/call.zig lowers each argument and passes it to the closure's trampoline WITHOUT running the coerceToType step that the normal sx-to-sx call path applies against the callee's declared parameter types. So a T → ?T wrap (and null → ?T) never happens for a closure value's optional param. A top-level fn call coerces args to param types, which is why norm works.

Investigation prompt

In src/ir/lower/call.zig, find the closure-value / fn-pointer call lowering (where %cl.fn/%cl.env trampolines are invoked — grep for cl.fn / the closure-call branch). Confirm it lowers args without coercing to the closure type's parameter types. The closure's parameter types are available from the Closure(...)/closure TypeInfo. Coerce each lowered argument to the corresponding parameter type via self.coerceToType(arg, arg_ty, param_ty) before building the call — mirroring the sx-to-sx call path. Verify:

1. The repro above: pick(7) → 99, pick(null) compiles and the body sees absent.
2. No regression in existing closure examples (examples/closures/).
3. Add a regression examples/closures/03xx-closure-optional-param.sx covering a concrete arg (wraps present) and a null arg (absent) into a closure-value ?T param.

Note: this is purely an argument-coercion gap at the closure-value call site; it is unrelated to the implicit-optional-unwrap family (issues 0179 / 0185), which is already fixed.