This'll match more closely what wasm eventually does natively, which is
importing these functions directly and not allowing changing them over time.
Closes#25
This commit migrates from `wasm_bindgen!`-the-macro to
`#[wasm_bindgen]`-the-attribute. The actual mechanics of the macro are
relatively simple in just generating some shims here and there, but wrapping
everything in one huge macro invocation can often seem intimidating as it gives
off this feeling of "oh dear anything can happen here!" Using an attribute
should curb expectations much more greatly of "oh there's just some extra stuff
happening behind the scenes".
The usage is otherwise relatively straightforward and close to what it was
before, but check out the DESIGN.md/README.md changes for more info!
Push the compiler to do trait resolution to figure out what each type is bound
with in JS, and that way we can accept effectively all types (so long as they
implement a trait).
This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent
discussions it's clear that the previous model wasn't quite going to cut it, and
this iteration is one which primarily embraces ES6 modules and the idea that
this is a polyfill for host bindings.
The overall interface and functionality hasn't changed much but the underlying
technology has now changed significantly. Previously `wasm-bindgen` would emit a
JS file that acted as an ES6 module but had a bit of a wonky interface. It
exposed an async function for instantiation of the wasm module, but that's the
bundler's job, not ours!
Instead this iteration views each input and output as a discrete ES6 module. The
input wasm file is interpreted as "this *should* be an ES6 module with rich
types" and the output is "well here's some ES6 modules that fulfill that
contract". Notably the tool now replaces the original wasm ES6 module with a JS
ES6 module that has the "rich interface". Additionally a second ES6 module is
emitted (the actual wasm file) which imports and exports to the original ES6
module.
This strategy is hoped to be much more amenable to bundlers and controlling how
the wasm itself is instantiated. The emitted files files purely assume ES6
modules and should be able to work as-is once ES6 module integration for wasm is
completed.
Note that there aren't a ton of tools to pretend a wasm module is an ES6 module
at the moment but those should be coming soon! In the meantime a local
`wasm2es6js` hack was added to help make *something* work today. The README has
also been updated with instructions for interacting with this model.
This commit adds an option to "uglify" the wasm module's imports/exports so
those which are controlled by bindgen are renamed to a shorter (probably one
letter) names. This'll hopefully help cut down on both the wasm size slightly
and also the generated JS as the glue we're talking to wasm over won't require
such large names all the time.
* Use a bundled custom `WasmRefCell` instead of the one in the standard library.
This one primarily doesn't panic via libstd which means that its code
footprint is much smaller.
* Add a `throw` function to `wasm_bindgen`-the-crate which can be used to throw
an exception in JS from Rust. This is useful as a cheap way to throw an
exception code-wise (little code bloat) and it's also a great way of reporting
error messages to JS!
* Cut down on the code size of `__wbindgen_malloc` by aborting on huge requests
earlier.
* Use a custom `assert_not_null` function which delegates to `throw` to test for
incoming null pointers
