Support JS libraries self-registering their exports with visibility attributes

[guybedford]

This implements support for JS libraries declaring their own public exports using per-symbol attributes, split out from #27208 as requested in review there.

The attributes separate symbol inclusion from export visibility:

• __export: true exports the symbol if it is otherwise included.
• __force: true includes the symbol even when nothing references it, without exporting it, analogous to DEFAULT_LIBRARY_FUNCS_TO_INCLUDE.
• Using both unconditionally includes and exports the symbol.

This allows binding layers such as wasm-bindgen to define a public JS API surface distinct from the wasm export names, including exported classes and namespaces:

addToLibrary({
  $Counter__export: true,
  $Counter__force: true,
  $Counter: class Counter { /* ... */ },
});

The attributes are consumed as JS library compile-time metadata and do not appear in generated output. The JS compiler forwards only the symbols actually emitted through extraExports, allowing the WASM_ESM_INTEGRATION wrapper to re-export them without mutating or returning the global EXPORTED_FUNCTIONS setting. Decorated exports are also retained through meta-DCE.

Test coverage verifies the independent attribute semantics under legacy modularized output, MODULARIZE=instance, WASM_ESM_INTEGRATION, and optimized -O3 builds, together with decorator validation.

Made with AI assistance under my review

[sbc100]

I think supporting something like this is a great idea but maybe we can bikeshed the design a little.

How about limiting this to symbols actually defined in the JS library itself using symbol attributes. Perhaps something like:

myLibrary = {
   foo: 42,
   foo__export: true,  // Export this symbol outside the module
   foo__alwasyInclude: true, // Include this symbol in the generated code, even if no other code depends on it.
}

I don't love the alwasyInclude name.. perhaps force?

In this scenario it would be possible to specify one of these without that other.

If you specified __export without __force then them symbol would be exported, but only if it was included for some reason.

If you specified __force without __export then the symbol would be included in the generated JS but not exported (similar to (similar to DEFAULT_LIBRARY_FUNCS_TO_INCLUDE).

I would hope that the information could all stay on the JS side, but if it needs to be plumbed back to python then it could then just be small extraExports list perhaps?

[guybedford]

I've updated this following the suggestion here for JS libraries to use the __export and __force symbol attributes:

• __export: export only when otherwise included
• __force: always include without exporting
• both: always include and export

The attributes are compile-time metadata and are not emitted. We no longer mutate or forward EXPORTED_FUNCTIONS, only actually emitted exports are returned as extraExports for the ESM wrapper.

Coverage includes legacy modules, instance ESM, WASM_ESM_INTEGRATION, and O3/meta-DCE.

[sbc100]

This is looking much better now! Thanks for being flexible.

[sbc100]

lgtm % comment.

Can you add a ChangeLog entry for this?

[guybedford]

Changelog added now as well.

[sbc100]

6.0.6 is about to be released in next few minutes/hours, so maybe we hold off landing this until after that happens in order to avoid having to move the changelog entry. See emscripten-core/emsdk#1774

[sbc100]

OK, 6.0.6 is now releases. Please rebase.

[guybedford]

Ok the Changelog entry is now updated to 6.0.7.