This commit starts to add a page of microbenchmarks for wasm-bindgen
which we can hopefully track and compare over time. Right now it's
primarily focused on data collection, making it easy to collect data
across a number of benchmarks for comparison. It doesn't currently do
much in the way of actually comparing the results for you (aka drawing
pretty graphs), so let's left for a future step.
It's hoped though that we can use this to track performance improvements
as well as ensuring that they work over time!
Run exports through the same identifier generation as imports to ensure
that everything gets a unique identifier and then just make sure all the
appropriate wires are hooked up when dealing with exports and imports.
Closes#1496
Currently the import object constructed for the `--target web` output
only ever includes the current module as an one of the modules included.
With `wasm-bindgen`'s optimization to import directly from modules,
however, it's possible to have more modules imported from in the
generated wasm file. This commit ensures that the imports are hooked up
in the `--target web` es6 emulation mode, ensuring there aren't
extraneous errors about import objects.
This commit fixes an issue where bindings for
`__wbindgen_object_drop_ref` are generated even if the function isn't
actually used by the final wasm file. This is currently due to the fact
that we run gc passes pretty late in wasm-bindgen and one of the
intrinsics that ended up getting gc'd referenced the
`__wbindgen_object_drop_ref` intrinsic function.
The fix here is somewhat naive by just updating the intrinsic to not
actually use `__wbindgen_object_drop_ref`. This may not be a long-term
solution but it should be good enough for now at least.
"Bindings for some variadic functions ..." line referenced irrelevant PRs.
Moved them to correct places and updated the line with relevant PR link instead.
We don't support variadic args in front, but, luckily for us, `new Function` accepts comma-separated args as a single string as well (see updated JSON test for an example).
- `JsString::from_code_point` - allows to create JS strings using slice of codes in WASM memory.
- `JsString::from_char_code` - same as above, but also uses updated signature with `u16` instead of `u32` (partially helps with #1460 at least for the new binding).
Now that functions and strings work properly with custom typechecks, these custom methods seem obsolete, so I'd recommend to use standard dyn_ref instead.
