Currently `#[wasm_bindgen]` generates a bunch of references to symbols that
don't actually exist on non-wasm targets, making it more difficult to get a
crate working across multiple platforms. This commit updates the symbol
references to be dummy ones that panic on non-wasm targets to allow simple
testing/benchmarking to work on native targets.
While this isn't a perfect solution for #114 it's probably as good as we can do
for now pending upstream Cargo features, so I'm gonna say that it...
Closes#114
These functions are activated with the `serde-serialization` feature of the
`wasm-bindgen` crate. When activated they will allow passing any arbitrary value
into JS that implements the `Serialize` trait and receiving any value from JS
using the `Deserialize` trait. The interchange between JS and Rust is JSON.
Closes#96
This commit adds a `#[wasm_bindgen(version = "...")]` attribute support. This
information is eventually written into a `__wasm_pack_unstable` section.
Currently this is a strawman for the proposal in ashleygwilliams/wasm-pack#101
Turns out there was a bug when passing a vector of `JsValue` instances back to
JS all objects were leaked rather than correctly removed from the global slab.
This commit fixes how the `getArrayJsValueFromWasm` function is defined to
correctly iterate over the slice by looking at the values rather than the
indices.
Closes#169
Using `proc-macro2`'s `nightly` feature is a good default for most use cases.
However, it causes a build error if used together with crates such as
`cssparser` that also use `proc-macro2` from a build script.
This change adds a default enabled feature `spans` that users can disable if
they need to work around this conflict.
Fixes#160.
Currently errors are reported via Rust panics but there's lots more errors being
added over time so this commit starts the movement towards the `failure` crate
to more idiomatically report errors as well as provide better error messages
over time.
The previous codegen wasn't enough to convince LLVM that the function pointer
was a constant value and could be aggressively inlined, so this updates the
`JsStatic` internals slightly to guarantee to LLVM that the function pointer is
constant and no dynamic dispatch is needed after all
Add support for `#[wasm_bindgen(readonly)]` which indicates that an exported
struct field is readonly and attempting to set it in JS will throw an exception.
Closes#151
Automatically infer public struct fields as "JS wants to access this" and
generate appropriate getters/setters for the field. At this time the field is
required to implement `Copy`, but we will probably want to relax that in the
future to at least encompass `JsValue` and maybe other `Clone` values as well.
Closes#121
Currently the entire `Program` is deserialized to match schema versions but this
is likely to fail when the schema changes. Instead just deserialize the
schema/version fields, compare those, and if successful go ahead and deserialize
everything.
This commit adds support for both `#![no_std]` in the wasm-bindgen runtime
support (disabled by default with an on-by-default `std` feature). This also
adds support to work and compile in the context of `#![no_std]` crates.
Closes#146
This commit adds support for closures with arguments like strings and such. In
other words, closures passed to JS can now have the same suite of arguments as
all functions that can be exported from Rust, as one might expect!
At this time due to the way trait objects work closures still cannot use types
with references like `&str`, but bare values like `String` or `ImportedType`
should work just fine.
Closes#104
This commit overhauls the conversion traits used for types crossing the Rust/JS
boundary. Previously there were a few ad-hoc traits but now there've been
slightly reduced and decoupled.
Conversion from Rust values to JS values is now exclusively done through
`IntoWasmAbi` with no special treatment for references. Conversion from JS to
Rust is a bit trickier as we want to create references in Rust which have
implications in terms of safety. As a result there are now three traits for
this, `FromWasmAbi`, `RefFromWasmAbi`, and `RefMutFromWasmAbi`. These three
traits are implemented for various types and specially dispatched to depending
on the type of argument in the code generator.
The goal of this commit is to lay the groundwork for using these traits in
closures with straightforward-ish definitions.
