sx/issues/0074-ffi-arg-type-void-fallback.md

0074 — silent getRefIRType(arg_ref) orelse .void fallback in FFI call-arg lowering

✅ RESOLVED. Root cause: four FFI call-arg lowering loops resolved an argument's IR type via getRefIRType(arg_ref) orelse .void — a silent fallback to the load-bearing real type .void, which downstream toLLVMType → abiCoerceParamType → coerceArg treat as a legitimate (void-typed) foreign argument, corrupting the call ABI with no diagnostic. Fix: one shared resolver LLVMEmitter.argIRTypeOrFail ([src/ir/emit_llvm.zig]) returns the dedicated .unresolved sentinel on a failed lookup — never .void/.s64 — so the failure cannot masquerade as a real type and trips toLLVMType's existing hard @panic tripwire at the call site. All four sites ([src/ir/emit_llvm.zig] JNI constructor; [src/backend/llvm/ops.zig] objc_msgSend, JNI non-virtual, JNI Call<Type>Method) now route through the helper. Happy path is byte-identical (every real arg already has a resolved type) — FFI examples stay green with zero snapshot churn. Regression test (fail-before/pass-after): src/ir/emit_llvm.test.zig — "argIRTypeOrFail surfaces .unresolved for an unresolvable FFI arg ref (issue 0074)".

Symptom

One-line: Four FFI call-arg lowering sites silently default a failed argument-type lookup to .void — the forbidden silent-type-fallback anti-pattern (.void as a failed-type-lookup sentinel), which would produce a void-typed foreign-call argument (wrong LLVM param type → silent ABI corruption) with no diagnostic if the lookup ever fails.

Observed: self.getRefIRType(arg_ref) orelse .void at:

• src/ir/emit_llvm.zig:2463
• src/backend/llvm/ops.zig:517 (Obj-C objc_msgSend arg loop)
• src/backend/llvm/ops.zig:731 (JNI non-virtual call arg loop)
• src/backend/llvm/ops.zig:761 (JNI Call<Type>Method arg loop)

Each then does toLLVMType(raw_ty) → abiCoerceParamType → coerceArg, so a .void fallback silently mis-types the foreign-call argument.

Expected: getRefIRType returning null for a real call argument is a "must-succeed lookup" failure (every arg is a valid param/instruction ref). Per CLAUDE.md REJECTED PATTERNS — ".void is an UNACCEPTABLE sentinel for a failed type lookup" — the lookup failure must surface as a diagnostic / hard tripwire, not a silently-corrupted argument type.

Provenance / scope

Pre-existing pattern (the emit_llvm.zig site is original; the three ops.zig sites were relocated verbatim, behavior-preserving by step A7.4c of the arch-refactor — the flow reviewer/observer correctly approved the relocations as equivalence-preserving). Surfaced by the A9.3 final fallback-audit of the arch-refactor stream. Not introduced by the refactor; filed per the IMPASSIBLE RULE ("If you find an existing default-return in the compiler that swallows a lookup failure, treat it as a discovered bug — file an issue, do not just delete the default in place").

Reproduction

This is a latent / static finding: there is no known sx program that drives getRefIRType to null for a valid foreign-call argument (well-formed IR always has a type for every arg ref), so it cannot currently be triggered at runtime — which is exactly why it is dangerous (a future IR change that breaks the invariant would corrupt FFI ABI silently). The code paths are exercised (and must stay green after the fix) by the existing FFI examples, e.g.:

examples/13xx-ffi-objc-*        # objc_msgSend arg lowering (ops.zig:517)
examples/14xx-ffi-jni-*         # JNI Call<Type>Method / non-virtual (ops.zig:731/761)

(No new minimal repro .sx is meaningful for a latent defensive fallback; the fix is verified by (a) the FFI suite staying green and (b) a unit test that asserts the new loud-failure path, see below.)

Investigation prompt (ready to paste into a fresh session)

In /Users/agra/projects/sx, four FFI call-arg lowering sites use the forbidden silent type-fallback self.getRefIRType(arg_ref) orelse .void (src/ir/emit_llvm.zig:2463; src/backend/llvm/ops.zig:517, :731, :761). getRefIRType (src/ir/emit_llvm.zig:2229, returns ?TypeId) yields null only when a ref is neither a function param nor a block instruction result — a must-not-happen case for a real call argument. Replace the silent .void default with a loud failure that cannot be mistaken for a real type, per CLAUDE.md REJECTED PATTERNS: emit a diagnostic via self.diagnostics.addFmt(.err, span, "...", .{...}) and/or a hard tripwire (@panic/bailDetail-style) naming the op and the bad ref — do NOT substitute another real type. Prefer a single shared helper (e.g. argIRTypeOrFail(arg_ref, span)) used by all four sites so the policy lives in one place. Then: (1) /Users/agra/.zvm/bin/zig build && /Users/agra/.zvm/bin/zig build test && bash tests/run_examples.sh must stay 361/0 with the FFI examples green (the happy path is unchanged); (2) add a *.test.zig unit test that constructs an FFI call op with a bogus arg ref and asserts the loud failure fires (not a .void silent default). Expected new behavior: an unresolved FFI arg type produces a clear compiler error / panic, never a void-typed foreign argument.