Heap-allocate patched interface vtable so it survives in a global __cctor

[ASDAlexander77]

Summary

Fixes a JIT crash (0xC0000005) when a top-level binding whose declared type is an interface is initialized from an object literal that has a method:

interface Counter { count: number; inc(): void; }
const counter: Counter = { count: 0, inc() { this.count = this.count + 1; } };
// counter.count / counter.inc() -> 0xC0000005

Root cause

Casting the (boxed) object literal to the interface builds a per-object vtable patched with the method's function pointer (mlirGenCreateInterfaceVTableForObject). That vtable was a stack VariableOp (alloca). For a local binding the alloca outlives its uses, but a global binding's initializer lowers to a __cctor function — so the alloca dangled once __cctor returned, leaving the interface's stored vtable pointer referencing freed stack memory. The crash then happened on the first field/method access through the interface.

Method-less interfaces (e.g. Point) were always fine: they point NewInterface directly at the shared global vtable, with no per-object patched copy.

Fix

Heap-allocate the patched vtable (NewOp + StoreOp + CastOp), putting it on the same footing as the object it describes (already NewOp-allocated). One localized change in MLIRGenInterfaces.cpp.

Test plan

• New regression test 00interface_global_method.ts (registered compile + jit). Also exercises two independent same-shape globals to confirm their per-object vtables don't alias.
• Full suite green: 354/354 JIT + 358/358 AOT (ctest -R "^test-jit-" / "^test-compile-" -j8).

Not covered (separate, still-open)

The cross-module (-shared) method-bearing interface case still crashes (null function-pointer call in the importer's __mlir_gctors) — a distinct issue in the shared-lib DLL-load / gctors-as-method symbol-resolution subsystem, not the vtable-lifetime bug fixed here. Documented in docs/object-literal-boxing-design.md §6 for follow-up.

🤖 Generated with Claude Code