This commit fixes instantiation of the wasm module even if some of the
improted APIs don't exist. This extends the functionality initially
added in #409 to attempt to gracefully allow importing values from the
environment which don't actually exist in all contexts. In addition to
nonexistent methods being handled now entire nonexistent types are now
also handled.
I suspect that eventually we'll add a CLI flag to `wasm-bindgen` to say
"I assert everything exists, don't check it" to trim out the extra JS
glue generated here. In the meantime though this'll pave the way for a
wasm-bindgen shim to be instantiated in both a web worker and the main
thread, while using DOM-like APIs only on the main thread.
When we add threads it's not actually valid to have a global cache as
the index is only valid on one thread! Instead let's use a per-thread
cache using `thread_local!` which compiles to basically the same code as
before for single-threaded wasm.
This commit adds support for the `slice` function on all `TypedArray`
instances. The `slice` function is similar to `subarray` except that it
actually copies the data, whereas `subarray` just returns a different
view into data.
The `JsValue` type wraps a slab/heap of js objects which is managed by
the wasm-bindgen shim, and everything here is not actually able to cross
any thread boundaries. When wasm actually has threads, for example, each
thread will have to have its own slab of objects generated by
wasm-bindgen, and indices in one slab aren't valid in any other slabs.
This is technically a breaking change because `JsValue` was previously
`Send` and `Sync`, but I'm hoping that in practice this isn't actually a
breaking change because nothing in wasm can be using threads which in
theory shouldn't activate the `Send` and/or `Sync` bounds.
The bindings generation for a class would accidentally omit the `__wrap`
function if it was only discovered very late in the process that
`__wrap` was needed, after we'd already passed the point where we needed
to have decided that.
This commit moves struct field generation of bindings much earlier in
the binding generation process which should ensure everything is all
hooked up by the time we generate the classes themselves.
Closes#949
The official pathname separator on Windows is `\` instead of `/`, but
we've been unconditionally using `/`. This typically works on Windows
because Cargo's default `OUT_DIR` listing is a normal `C:\...` path
which works with either `/` or `\`. If, however, a user sets
`CARGO_TARGET_DIR` to a UNC-style path like `\\?\C:\...` then `/` is
*not* the same as `\`, but rather `/` is interpreted as part of the file
name (to allow file names with `/` in the name).
Let's bypass all this and just use a build script output env var.
Closes#943
These compiler bugs have now been fixed on nightly, so we just need to
wait for the bug fixes to ride the trains to be available to everyone!
Closes#201
The `wasm-bindgen` crate is effectively the only user of this crate now
that the `wasm-gc` tool has been deprecated. It's also much easier to
keep it in this repository as it's easier to sync changes to
`parity-wasm`. I'd also like to start refactoring out utilities for
managing a `parity_wasm::Module` to share between this crate and the
other CLI support code.
