Spread method call on an imported-array receiver is wrong (arr.map(...[cb]), arr.slice(...[1,3]))

[proggeramlug]

Summary

A spread method call whose receiver is an imported binding (arr.map(...[cb]) where arr comes from another module) produces wrong results or throws. Pre-existing on d8be5f4a2; the failure shape changes with #7188 but it is wrong in both arms.

Repro

lib.ts

export const arr = [3, 1, 2];
export const nums: number[] = [10, 20, 30];

main.ts

import { arr, nums } from "./lib.ts";
const cb = (x: number) => x * 2;
console.log(JSON.stringify(arr.map(...([cb] as [any]))));
console.log(JSON.stringify(arr.slice(...([1, 3] as [any, any]))));
console.log(JSON.stringify(nums.join(...(["-"] as [any]))));
console.log(JSON.stringify(nums.includes(...([20] as [any]))));

case	node 26.5.1	perry d8be5f4a2	perry with #7188
arr.map(...[cb])	[6,2,4]	TypeError: object is not a function	TypeError: Cannot convert undefined or null to object
arr.slice(...[1,3])	[1,2]	[3,1,2] (silently wrong)	[]
nums.join(...["-"])	"10-20-30"	TypeError: Cannot convert undefined or null to object	same
nums.includes(...[20])	true	false (silently wrong)	TypeError: Cannot convert undefined or null to object

4/4 wrong before, 4/4 wrong after — #7188 is not a regression here, but two cases move from a silently-wrong value to a throw, and one moves from one wrong value to another.

Where it comes from

crates/perry-hir/src/lower/expr_call/imported_array_methods.rs carries a note from #6718:

a spread method call on an IMPORTED array … is intentionally NOT declined here … The imported binding lowers to an ExternFuncRef receiver, which that [generic Expr::CallSpread] tail's member-callee arm skips (it may be an imported function), so routing there would fail to dispatch the native method.

That is the bug: the generic CallSpread tail declines member callees on ExternFuncRef receivers, so the spread call never dispatches the receiver's method. The imported-array fold was papering over it — and it papered badly (slice/includes were already returning wrong values, since the spread argument list arrives as a single array in the builtin's first slot). The test_gap_6718_spread_call_native_method repro covers inline literals, local receivers and queueMicrotask — not imported receivers — so this has never been under test.

Fix belongs in the CallSpread member-callee arm: let it dispatch on an ExternFuncRef receiver instead of skipping.

Environment

Node 26.5.1 (.node-version pin), perry @ d8be5f4a2, macOS arm64, PERRY_NO_AUTO_OPTIMIZE=1. Found while investigating #7154 / #7188.

Refs #7154, #7188, #6718.

[proggeramlug]

Confirmed on Windows x86-64; and a warning about the obvious-but-wrong fix

Reproduced at 0f9bb6cc5 (perry-dev) against node 26.5.1, with an imported export const arr: number[]:

call	node	perry
arr.map(...[cb])	[10,20,30,40]	TypeError: Cannot convert undefined or null to object
arr.slice(...[1,3])	[2,3]	(dies at line 1)
arr.join(...['-'])	1-2-3-4	(dies at line 1)
arr.indexOf(...[3])	2	(dies at line 1)
arr.map(cb) / arr.slice(1,3)	ok	ok ✅

Not platform-specific. Note the failure is now a hard throw, not the silent wrong values recorded in the #6718 note (slice(...[1,3]) returning the whole array, includes(...[20]) returning false) — worth knowing when writing the acceptance test.

Warning for whoever picks this up. The tempting fix is wrong, and the evidence points straight at it:

$ grep -c "spread.is_some()" crates/perry-hir/src/lower/expr_call/*_array_methods.rs
inline_array_methods.rs:    1
local_array_methods.rs:     4
array_only_methods.rs:      3
imported_array_methods.rs:  0     <- the odd one out

Three of the four sibling fold files carry the #6718 "decline on any spread" guard and imported_array_methods.rs does not, which reads exactly like a missed case. It isn't. The note at imported_array_methods.rs:66-79 records that this was already measured: 4/4 wrong before adding a guard and 4/4 wrong after, because the generic Expr::CallSpread tail's member-callee arm skips ExternFuncRef receivers (they may be imported functions, not arrays). Declining the fold just moves the failure.

So the fix has to be the one that note names: teach the CallSpread member-callee arm to dispatch on an ExternFuncRef receiver — flattening the spread into one argument array and dispatching the array method by name with this bound to the receiver (js_native_call_method_apply_by_id), which is what the local/inline/any-expression receivers already do. Adding the guard to imported_array_methods.rs is only safe after that tail works, and is optional even then.

I nearly shipped the guard-only change before reading that note; recording it here so the next person doesn't.

Found while landing #7470 / #7471.

[proggeramlug]

Attempted the documented fix — it is necessary but NOT sufficient; there is a third blocker

Follow-up to my previous comment. I implemented both halves and the repro still fails identically, so recording the dead end.

What I changed (now reverted):

1. perry-codegen/src/expr/call_spread.rs:~208 — the member-callee arm unconditionally skips ExternFuncRef receivers ("means a top-level imported function reference, not a method"). I relaxed it to admit an ExternFuncRef whose declared return_type is an array, mirroring imported_binding_is_array in perry-hir. This is the tail the #6718 note says the fix depends on.
2. perry-hir/.../imported_array_methods.rs — added the sibling #6718 spread guard, so the fold declines and the call actually reaches that tail. Without this the fold claims arr.map(...[cb]) first and no CallSpread is ever built, which is why the original measurement saw no change from the guard alone.

Result: still TypeError: Cannot convert undefined or null to object, unchanged. So the two-layer model in the code comment is incomplete — something upstream still claims the call, or an imported export const arr: number[] receiver does not reach codegen as an Expr::ExternFuncRef with an Array return_type at all (worth dumping --print-hir on the repro first; that is the cheapest next probe and I did not get to it).

Net for the next person: the #6718 note's stated fix ("let the CallSpread tail dispatch on an ExternFuncRef receiver") is necessary but not sufficient, and the guard-plus-tail combination is still not enough. Start by confirming what the receiver actually lowers to rather than by editing either site.

Reverted; nothing shipped for this issue.

[proggeramlug]

Found the third blocker: the imported binding's array type never crosses the module boundary

Ran the --print-hir probe I said was the cheapest next step. It settles it:

CallSpread {
  callee: PropertyGet {
    object: ExternFuncRef { name: "arr", param_types: [], return_type: Any },
                                                        ^^^^^^^^^^^^^^^^^^
    property: "map", .. },
  args: [Spread(Array([LocalGet(0)]))] }

while the defining module has it as Let { name: "arr", ty: Array(Number), .. }.

So lookup_extern_func_types hands back Type::Any for import { arr } from "./mod.ts" even though the source module declares export const arr: number[]. Two consequences, and they explain everything observed so far:

1. imported_binding_is_array already returns false, so the #7154 gate at imported_array_methods.rs:114 declines before reaching any method arm. The fold was never firing for this shape — which is why adding the sibling spread guard changed nothing, and equally why the original "4/4 wrong before and after" measurement came out flat. The guard is a no-op here.
2. My codegen predicate could never fire either. I gated the call_spread.rs skip-relaxation on return_type being an array type, mirroring imported_binding_is_array — but that evidence does not exist at this point, so the receiver kept getting skipped.

Revised fix shape. There is no array evidence to gate on, so the two candidate fixes are:

• (a) Fix the root — propagate the exported binding's declared type across the module boundary so ExternFuncRef.return_type is Array(Number) rather than Any. This is the better fix: the #7154 invariant in imported_array_methods.rs is built on that type evidence ("the only positive evidence available is the declared type"), so today that whole fold is silently dead for typed array imports, and every ordinary CHAIN_NAMES.map(fn) is taking the generic path. Worth measuring as a perf item independently of this bug.
• (b) Relax the call_spread.rs skip without array evidence — narrower, but the skip exists because object may be an imported function (sql.join(...), the Compile drizzle-orm end-to-end via perry.compilePackages #420 drizzle shape), and with return_type: Any there is nothing to distinguish the two. Needs care, and (a) would make it unnecessary.

I'd pursue (a). Note it may also change behavior of the existing folds that have been dormant, so it wants a parity sweep, not just this repro.

Everything I tried is reverted; nothing shipped. Prior comments in this thread describe the two layers I ruled out.

[proggeramlug]

Why fix (a) is architectural, not a small patch — closing out my investigation

Checked where extern_func_types is populated. There is exactly one writer:

crates/perry-hir/src/lower/lower_module_fn.rs:614
    ctx.register_extern_func_types(func_name, param_types, return_type);

and it sits inside the arm for ambient function declarations with no body ("No implementation exists — treat as external FFI declaration"). An imported value binding — export const arr: number[] — never passes through it, so lookup_extern_func_types misses and the caller falls back to Type::Any. That is not a bug in the lookup; the table was only ever meant to hold FFI function signatures.

Getting the real type there means propagating the source module's exported-binding type to the importer at HIR-lowering time, and that is the hard part: modules are lowered independently and an importer may be lowered before its source. The compile driver does have both modules' HIR (that is where run_pipeline resolves cross-module namespace/export info), but the fold decision in imported_array_methods.rs happens strictly earlier, during lowering. So either the type has to be pre-resolved into lowering, or the array-fold decision has to move later.

Summary of the three layers, all now ruled out at their natural site:

candidate	verdict
add the sibling #6718 spread guard to imported_array_methods.rs	no-op — the #7154 type gate already declines first, since the type is Any
let call_spread.rs admit an ExternFuncRef receiver (the fix the code comment names)	cannot fire — I gated it on array-ness, and no array evidence exists at that point
propagate the declared array type across the module boundary	correct, but architectural — needs cross-module types available during lowering

Worth noting the second-order finding: because the type is Any, the #7154 gate declines for every typed array import, so the whole imported_array_methods fold is effectively dormant and ordinary CHAIN_NAMES.map(fn) already takes the generic path. Fixing the type propagation would wake ~20 folds at once, so it wants a full parity sweep rather than this repro alone — and it may be worth deciding whether those folds are wanted at all before reviving them.

Everything reverted; nothing shipped for this issue.