Fix const and destructuring locals in modules imported as source

[ASDAlexander77]

Summary

import './lib' fell over whenever lib.ts read a local const in any function. It also failed on array or object destructuring in a function body, with let too.

When no shared library sits beside the importer, lib.ts is included as source in declaration mode. Its functions become declarations, and their bodies are walked only to infer types. In that walk, every variable's initializer was evaluated for its type alone, locals included, so a local had no value:

In a function of the imported module	Importer's compile, before
const s = n + 1; return s;	error: can't resolve name: s
const [a, b] = [n, n + 1]; (or let)	error: failed statement
const { x, y } = { x: n, y: 5 }; (or let)	compiler crash

A const binds its name directly to its value, and a destructuring pattern reads its elements from the value, so both need one. let survived because it gets storage.

Fix

mlirGen(VariableDeclaration) in MLIRGenVariables.cpp: the type-only initializer now applies only to module-level variables (declarationMode && !genContext.funcOp). Locals get real values. The bodies are a dummy run whose IR is discarded, so nothing extra reaches the output.

A first attempt gave the const storage instead, and was rejected. The name then reads as the storage reference, so a function without a return annotation inferred ref<number> in the importer and number in the library. The class-method call then crashed at run time (0xC0000409). The tests include an inferred-return function for that reason.

Tests

import_const_locals.ts / export_const_locals.ts cover:

• a plain value, a string, and a return type inferred from a const
• a loop, an if block, a class method, and a namespace function
• array and object destructuring

They're registered three ways:

• test-compile-export-import-const-locals: static multi-file. This is the mode that includes the library as source and exercises the fix.
• test-compile-shared-export-import-const-locals and test-jit-shared-export-import-const-locals: these read the DLL's declarations instead, and stay as regular coverage.

The ownership verifier also compiles import_const_locals.ts alone, which includes the library as source.

Per-feature pairs checked before and after the fix, in all three modes: everything above fails before and passes after.

Not covered: an exported arrow function (export const f = (n) => {...}) fails across modules even without a const inside. That's a separate bug, filed as #311, and left out of the test pair.

Test plan

• The three new tests pass
• Full ctest, Windows release, before merging main: 2,707 of 2,707
• Full ctest, Windows release, after merging main (with One garbage collector per process: linkage choice, import checks, Linux, default-library tests #310): 2,710 of 2,710
• CI green on Windows and Linux, including the merge with One garbage collector per process: linkage choice, import checks, Linux, default-library tests #310 (Windows needed one rerun: the known intermittent 00try_finally_return failure, "reference to block defined in another region", which also hit One garbage collector per process: linkage choice, import checks, Linux, default-library tests #310)

🤖 Generated with Claude Code