lab/sx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: dispatch unwrapped optional-closure call g!() through call_closure (issue 0170)

Browse Source 
Calling through an unwrapped optional closure (g!()) crashed with LLVM
'Called function must be a pointer!': the indirect-call catch-all else
arm emitted call_indirect on the whole {fn,env} closure struct with a
hardcoded .i64 return. The else arm now inspects inferExprType(callee):
a .closure callee dispatches through call_closure (threads env + ctx via
the [ctx, env, user_args] ABI, returns closure.ret); a plain fn pointer
uses call_indirect with the callee's real function.ret instead of i64.

The filed repro's ?(() -> void) spelling is a tuple-optional (now
diagnosed by the 0165 fix); the real ?Closure(...) layout was already
correct. Verified load-bearing (HEAD crashes) by 3 adversarial reviews,
suite 785/0. Regression: examples/closures/0311-closures-optional-closure.sx.
Filed adjacent bug 0177 (array-element closure direct call crashes).
This commit is contained in:
agra
2026-06-23 01:02:13 +03:00
parent 28bb101a4a
commit 3605165398
7 changed files with 170 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
issues/0170-closure-optional-layout-truncated.md
View File

@@ -1,5 +1,22 @@
# 0170 — closure optional `?(() -> ...)` alloca is sized one word, truncating the `{fn,env}` closure value
> **RESOLVED** (root cause differs from the title's hypothesis). Two findings:
> (1) the filed repro's `?(() -> void)` spelling is a TUPLE-optional (the `(T)`
> 1-tuple rule), now correctly diagnosed by the issue-0165 fix — not a closure
> bug. (2) The REAL closure-optional `?Closure(args) -> R` layout was already
> correct (sentinel form: the value IS the closure `{fn,env}`, has_value =
> `fn_ptr != null`); `if g` / `== null` / `!= null` already worked. The genuine
> bug was calling through an unwrapped optional closure `g!()` — the indirect-call
> catch-all `else` arm (`src/ir/lower/call.zig`) emitted `call_indirect` on the
> whole `{fn,env}` struct (LLVM "Called function must be a pointer!") with a
> hardcoded `.i64` return. Fix: the `else` arm inspects `inferExprType(callee)` —
> `.closure` → `call_closure` (threads env+ctx, returns `closure.ret`); else →
> `call_indirect` with the callee's real `function.ret`. Verified load-bearing
> (HEAD crashes) by 3 adversarial reviews; suite 785/0. Regression:
> `examples/closures/0311-closures-optional-closure.sx`. (Adjacent pre-existing
> bug found + filed: 0177 — array-element closure direct call `fns[i](args)`
> crashes.)
## Symptom
An optional of a closure (`?(() -> void)`, `?Fn`) is mis-laid-out: the optional

41
issues/0177-array-element-closure-direct-call-crashes.md Normal file
View File

@@ -0,0 +1,41 @@
# 0177 — calling a closure stored in an array element directly (`fns[i](args)`) crashes / miscompiles
## Symptom
A closure (or `Closure(...)`-typed value) stored in an array, called DIRECTLY via
index (`fns[i](args)`), does not dispatch through the closure ABI: it emits a bare
`call_indirect` on the whole `{fn,env}` struct → LLVM "Called function must be a
pointer!" (verify fail) for some return/arg shapes, or returns garbage for others.
Pre-existing (reproduces on master); distinct from issue 0170 (which fixed the
unwrap-through-optional call `g!()`). Here the callee is a non-optional closure
reached via array index, called directly without unwrap.
## Reproduction
```sx
#import "modules/std.sx";
add :: (a: i64, b: i64) -> i64 { return a + b; }
main :: () {
fns : [1](Closure(i64, i64) -> i64) = .{ add };
print("{}\n", fns[0](3, 4)); // LLVM "Called function must be a pointer!" — expected 7
}
```
Expected: `7`. Observed: LLVM verification failure (or, for other shapes, garbage
return / f64-arg verify failure).
## Investigation prompt
`src/ir/lower/call.zig`: issue 0170 added closure-vs-fn-pointer dispatch to the
indirect-call catch-all `else` arm via `inferExprType(callee)` → `.closure` →
`call_closure`. A direct call whose callee is an ARRAY-INDEX expression
(`fns[0]`) of closure type apparently does not reach that dispatch — either it
takes an earlier call arm that still emits `call_indirect`, or
`inferExprType(index_expr)` does not return `.closure` so the `else` arm falls to
the fn-pointer path. Trace which arm `fns[0](args)` lowers through and ensure a
closure-typed callee — regardless of whether it's a bare ident, field access,
index, or call result — dispatches through `call_closure` (threading env + ctx
via the `[ctx, env, user_args]` ABI). Compare with the working `arr[i]!()`
(unwrap) path. Follow the no-silent-fallback rule. Verify: `fns[0](3,4)` → 7;
array-of-closure with captures; non-i64 returns (void/f64/struct); f64 args.
Add an `examples/closures/03xx-array-of-closures-call.sx` regression.