An exported variable beside top-level code is exported (#448)

[ASDAlexander77]

With -shared, the importer of export const k = 5; from a module that also had a top-level statement couldn't resolve k ("can't resolve name: k"), under every memory model.

A root with top-level code generates its own variable statements inside its entry function (generateGlobalEntryCode), where they stay module globals. But the export check treated any enclosing function as making a variable local (isExport = !genContext.funcOp && ...). So k never reached the library's __decls, and the library ended up with no __decls at all.

The context generateGlobalEntryCode gives the root's statements now records the entry function (rootStatementsFuncOp). A variable declared directly in that function counts as module level for the export check. A function nested inside those statements has a funcOp of its own, so --export=all still leaves function locals alone.

The importer also warned 'let' does not have initializer at the import, with or without top-level code. The library declares k to its importers as @dllimport let k : s32;, and the variable is defined in the library. A declaration with @dllimport no longer gets the warning, just as a declare declaration doesn't.

New tests import-source/import_export_const.ts + export_const_module.ts run compiled, -shared (the failing case on main), JIT with -shared, and JIT. Both -shared runs also fail if the warning appears.

Gate	Result
Windows full suite (Release)	3834/3834
Linux (WSL) full suite	3819/3819
DefaultLib build + its own tests.ps1 -Model, release + debug, compile + JIT	gc 159/159; rc, none 158 passed + weakref_basic skipped (gc only); all "All tests passed"
own corpus	no flips, no first-error changes (460/618)

Closes #448

🤖 Generated with Claude Code