Reported in #1191 the fix requires us to get a bit creative I think. The
general gist is that a block like this:
#[wasm_bindgen]
impl Foo {
pub fn foo() {}
}
was previously expanded all in one go. Now, however, it's expanded into:
impl Foo {
#[__wasm_bindgen_class_marker(Foo = "Foo")]
pub fn foo() {}
}
// goop generated by orginal #[wasm_bindgen]
This method of expansion takes advantage of rustc's recursive expansion
feature. It also allows us to expand `impl` blocks and allow inner items
to not be fully expanded yet, such as still having `#[cfg]` attributes
(like in the original bug report).
We use theinternal `__wasm_bindgen_class_marker` to indicate that we're
parsing an `ImplItemMethod` unconditionally, and then generation
proceeds as usual. The only final catch is that when we're expanding in
an `impl` block we have to generate tokens for the `Program`
(wasm-bindgen injected goop like the custom section) inside the body
of the function itself instead of next to it. Otherwise we'd get syntax
errors inside of impl blocks!
Closes#1191
This commit migrates all our examples to using `wasm-pack build` to
compile their code and run `wasm-bindgen`. This should make it a bit
easier to understand the examples as there's less to follow during the
build step.
Webpack projects are all using `@wasm-tool/wasm-pack-plugin` as well so
the build step is simple `npm run serve`. Other examples which retain
`build.sh` are just using `wasm-pack build` now
This commit updates the `--debug` output of `wasm-bindgen` from the CLI
to catch all JS exceptions from imported functions, log such, and then
rethrow. It's hoped that this can be used when necessary to learn more
information about thrown exceptions and where an uncaught exception
could be causing issues with Rust code.
Closes#1176
