[ASDAlexander77]

Problem

interface HasFn { fn: () => int; }
let k = 5;
const cl = () => k + 1;
const o = { fn: cl };
const h: HasFn = o;   // warning: Cloned object is used
print(h.fn());        // printed garbage (-1962833079), expected 6

The literal stores cl as a bound function (its this is the capture tuple); the interface slot is read as a function taking the object as its this (func<opaque, si32>). The cast cloned the object with the interface's field type, and bound_func -> func<opaque> dropped the captures, so the call bound the object where the captures belonged.

Probing turned up related cases with the same cause:

• a type-literal annotated field (const o: { add: (a: int) => int } = { add: (a) => a + k }) holds a hybrid function: it worked only while it captured nothing, and crashed once it did
• an interface method (fn(): int) filled by the closure field: garbage
• a plain function with parameters ({ add: plusOne }): got the object as its first argument
• a literal built for the interface (return { fn: cl } from a function returning HasFn) cast the closure while building the literal

Fix

A field holding a function the interface can't call with the object as this (bound, hybrid, or a plain function without a this parameter: MLIRTypeHelper::isObjectFieldFunctionWithoutThis):

• matches the interface's function-typed member as it is (getInterfaceVirtualTableForObject), and keeps its own type in a clone (getInterfaceCloneFields) and in a literal built for the interface (addObjectFieldInfo)
• is called through a thunk <vtable>.<field>.thunk(this, ...) { return this.<field>(...) } (generateSynthMethodToCallField, which now takes the this type and is shared with the class path from A class method can fill an interface's function-typed field #612). A method's slot holds the thunk, and a function-typed field's slot holds a method cell tagged with INTERFACE_METHOD_CELL_TAG, as A class method can fill an interface's function-typed field #612 does for classes. The per-cast method patch skips these slots.

Object-literal methods (fn() {...}, or arrows written inside the literal) take the object, so they keep the direct path.

The object's cell uses the {method, flag offset} layout from #615, with -1 (always present). Writing through the interface stays an error ("saving to constant object"), as #615 made it.

Tests

00interface_function_typed_field_object_closure.ts (AOT and JIT, plus rc/none corpus) covers: a capturing closure in a field and a method, a live capture (k = 10 is seen), a closure with a parameter, a hybrid annotated field, plain functions, a clone forced by another field, a literal typed by the interface, an escaping closure returned from a function and used in an array, an optional field, and an object-literal method. It failed before the fix (garbage, then an assert).

Full ctest -C Release -j 16 --timeout 300: 4736/4736 passed on the first push (2 skipped, 1 disabled, as on main), and 4742/4742 after merging main (#615).

🤖 Generated with Claude Code