[ASDAlexander77]

PR 1 of the plan in docs/superpowers/specs/2026-09-25-tsbindgen-linkname-design.md. It adds @linkname("sym") as a second spelling of @dllname("sym"). It also fixes two bugs that stop a C function being bound under another TS name. tsbindgen (the stacked PR) needs these fixes for its --namespace output.

Changes

@linkname is an alias of @dllname. Both spellings map to the same DLL_NAME attribute in iterateDecorators, so everything that already reads @dllname accepts @linkname, including __decls, which still prints @dllname(...). Using both on one declaration with different symbols is an error. Using both with the same symbol is allowed.

Several declarations of one C symbol now bind it together. The rename used to happen in LLVM (ExportFixPass). When the name was already taken, setName quietly made it unique:

declare function strlen(s: string): index;
@linkname("strlen") declare function cStrLen(s: string): index;
@dllname("strlen")  declare function cStrLen2(s: string): index;

• Before: the IR had @strlen, @strlen.1 and @strlen.2. The JIT failed with Symbols not found: [ strlen.1, strlen.2 ] and the exe with LNK2019: unresolved external symbol strlen.1.
• After: all three calls go to strlen, both linked and under the JIT (declare_linkname_shared_symbol.ts).

The rename now happens in MLIR (LowerToLLVM.cpp, beside the existing global rename). Declarations of one symbol are merged. Everything else is an error instead of a silent .1:

• two different function types;
• two definitions;
• a target that is a global variable;
• a rename to a name another rename just gave up (either order).

The error cases are the test-compile-linkname-* tests.

export declare no longer marks the C function dllexport. A declaration without a body stops getting the export attribute. Whether it is re-printed into __decls is unchanged. test-compile-linkname-declare-not-exported checks the IR has no declare dllexport.

• An exe that export declares strlen still writes a .lib/.exp. Those come from the module's own __decls/__tsmm dllexport globals, which are exported on purpose.
• strlen itself was not exported before this change and is not exported after it. The spec said the exe "re-exports strlen" and blamed it for the .lib; that was wrong, and the spec has been corrected.

Existing bug found while testing: a function carrying @dllname/@linkname was private. Under --opt, inlining plus SymbolDCE deleted it before it could be renamed. That is why @dllname definitions went missing under --opt. Such functions are now public.

Also on this branch

• Spec and plan documents: the design spec, and the PR 1 and PR 2 plans (docs/superpowers/).
• 601ea68, JIT: --emit=jit now runs a main(argc, argv) that takes parameters and returns a result, and defaults to -O3. Test: 00main_argc_argv.ts, 00main_number_result.ts. Two AOT problems are still open:
  • argv.length reads envp;
  • a main returning number doesn't give a proper exit code.
• 0dbb472: the VS Code template's CMake minimum version (3.21).

Tests

Full Release suite on Windows: all pass, with one test disabled.

The disabled test is test-compile-shared-export-import-declare-linkname. Importing a -shared module's export declare binding of a C runtime function crashes: the importer looks strlen up in the loaded tslang libraries, which never contain it. A build from before this branch crashes the same way with @dllname, so this is an existing bug: #368. Its static-link twin, test-compile-export-import-declare-linkname, passes and guards the same path.

Known gaps

• Error messages name the already-renamed symbol ('strlen') rather than the TS name.
• A global whose @linkname target is a function gives an internal "failed to legalize" error instead of a clear one. @dllname already behaved this way.

🤖 Generated with Claude Code