Treat exported consts as variables; fix const functions across modules

[ASDAlexander77]

Summary

Fixes #311. A module-level const holding a function can now be used from another module. The rule: an exported module-level const is a variable, like an exported let, and importers read the function out of it.

Why it broke

The library compiled export const f = (n) => ... into a function named f: the arrow function took the const's name, and isGlobalConstLambda erased the global. Importers still looked for a variable f:

	Before
static multi-file	undefined symbol: f
-shared	wrong result
-jit -shared	crash 0xC0000005: the importer loaded a "pointer" from the function's code bytes

export const g = function () {...} had no g symbol at all.

Fix

• Exported const → let (mlirGen(VariableDeclarationList)): an exported, module-level, non-import const becomes Let.

  • Its global stays.
  • __decls prints let f : ....
  • A module including the source declares the same variable.
  • Non-exported consts keep the fold-into-a-function optimisation.

• Function-typed globals other modules reach are hybrid functions (adjustGlobalVariableType), as a local let already was.

  • The __decls type (p0: number) => number reads back as a hybrid function.
  • The library had inferred a plain function, which stores a smaller value, so under -shared the arguments landed in the wrong place. Before this, export let f = (n) => n * 3; f(2) printed 0 under -shared; it now prints 6.

• isGlobalConstLambda only erases a const that is the function: the initializer is a function named after the const. Otherwise the global is kept, which fixes these cases in the module itself:

  • const alias = namedFunction
  • a module-level const g = function* () {}, whose generator wrapper has another name

  Both failed with can't resolve name before.

• Function expressions take the const's name like arrow functions. The receiver name is the short name, so a namespaced one no longer prints NS.f inside namespace NS { }.

Tests

import_const_functions.ts / export_const_functions.ts cover:

• block and expression arrows
• a function expression
• an arrow with a const local
• an exported alias of a named function
• an exported let arrow
• a non-exported const arrow used by an exported function
• a non-exported generator const
• a const arrow in a namespace

They're registered as static multi-file, -shared, and -jit -shared.

Also checked in all three modes:

• an async arrow const
• a const function expression
• an exported number const
• let values under -shared: a number literal, a computed number, a pointer to a named function, and an arrow

Not covered

An exported generator is still wrong under -shared, whether export function* g() or export const g = function* .... Its __decls return type prints the boxed generator object as a value tuple (() => {.step:s32, next(): ...}). It fails the same way on main and is filed separately.

Test plan

• New tests fail before the fix and pass after
• const-locals tests (Fix const and destructuring locals in modules imported as source #312) still pass
• Full ctest, Windows release: 2,713 of 2,713
• CI green on Windows and Linux (the first push failed to compile on Linux: a dependent .as<T>() in the getTypeAndInit template needed .template, fixed in f6d7a99)

🤖 Generated with Claude Code