-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Unify wasm-bindgen output under -sWASM_BINDGEN, add -sWASM_BINDGEN=auto #27208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -238,7 +238,15 @@ function checkUnflushedContent() { | |
| #endif // EXIT_RUNTIME | ||
| #endif // ASSERTIONS | ||
|
|
||
| #if WASM_ESM_INTEGRATION && WASM_BINDGEN | ||
| // wasm-bindgen's glue reaches the wasm exports by name on an aggregate exports | ||
| // object, so provide it via a namespace import. Only under WASM_BINDGEN - | ||
| // plain ESM integration keeps per-symbol named imports so bundlers can | ||
| // tree-shake unused wasm exports. | ||
| import * as wasmExports from './{{{ WASM_BINARY_FILE }}}'; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One of them primary reason we are pushing for WASM_ESM_INTEGRATION is to avoid this kind of thing, since I assume once your do this it makes DCE in the bundlers a lot harder/more complicated. Presumably most programs don't actually need access to the full set of
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've restricted this to the WASM_BINDGEN mode only. Note that namespaces in JS bundlers are still fully tree-shakable as they are themselves fully statically analyzable so far as they do not escape analysis paths (which they usually don't so long as they aren't passed around). |
||
| #elif !WASM_ESM_INTEGRATION | ||
| var wasmExports; | ||
| #endif | ||
| #if SPLIT_MODULE | ||
| var wasmRawExports; | ||
| #endif | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| [build] | ||
| target = "wasm32-unknown-emscripten" | ||
| rustflags = [ | ||
| "-Cllvm-args=-enable-emscripten-cxx-exceptions=0", | ||
| "-Cpanic=abort", | ||
| "-Crelocation-model=static", | ||
| ] |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,10 @@ | ||
| [package] | ||
| name = "bindgen_greeter" | ||
| edition = "2021" | ||
|
|
||
| [[bin]] | ||
| name = "bindgen_greeter" | ||
| path = "src/main.rs" | ||
|
|
||
| [dependencies] | ||
| wasm-bindgen = "=0.2.126" |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| use wasm_bindgen::prelude::*; | ||
|
|
||
| #[wasm_bindgen] | ||
| pub struct Greeter { | ||
| greeting: String, | ||
| } | ||
|
|
||
| #[wasm_bindgen] | ||
| impl Greeter { | ||
| #[wasm_bindgen(constructor)] | ||
| pub fn new(greeting: String) -> Greeter { | ||
| Greeter { greeting } | ||
| } | ||
|
|
||
| pub fn greet(&self, name: String) -> String { | ||
| format!("{}, {}!", self.greeting, name) | ||
| } | ||
| } | ||
|
|
||
| fn main() { | ||
| // Matches the emscripten idiom: main runs automatically on init. | ||
| println!("main ran"); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This new feature I think maybe requires a little attention.
I assume this is to that JS librarys can do things like:
?
I'm not sure how common this need is going to be. I wonder if there are any use cases in the emscirpten itself where we had to hack around the lack of this feature?
Could you share an example of exactly how/when wasm-bindgen adds to this list?
Normally settings flow in single direction "emcc -> js compiler" having settings flow back like this is maybe a little scary.
At the very least, I think we should land this as a separate PR adding this as a new feature with it own specific test case in
test/test_jslib.jsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Wasm Bindgen you can declare, e.g. a JS class export:
This is then provided as
import { Counter } from 'mod'whereCounter.prototypeis configured correctly.The name of the prototype is handled via configuration (with name modifers such as
js_nameandjs_namespace), and is distinct from the name of the Rust mangled constructor function.So the actual wasm bindgen exports are an entirely different layer to the Wasm module exports.
This allows us to drive this information back into the Emscripten linker.
The naive implementation is not possible because we currently spill all internal exports as public so do need to add filtering in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've gone ahead and split this out into #27436. This will be a prerequisite for this PR still.