These are bindings to JavaScript's standard, built-in objects and their methods
and properties.
This does *not* include any Web, Node, or any other JS environment APIs. Only
the things that are guaranteed to exist in the global scope by the ECMAScript
standard.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects
* backend comments complete
* better matching
* gen comments
* Add example
* Move test bindings gen to own fn
* move build step into build fn
* add fn to read js, refactor gen_bindings/test to allow for this
* Add comments test
* Update readmes
* add comments to travis
* fix broken tests
* +x on build.sh
* fix wbg cmd in build.sh
* Address fitzgen's comments
This commit is an implementation of mapping u64/i64 to `BigInt` in JS through
the unstable BigInt APIs. The BigInt type will ship soon in Chrome and so this
commit builds out the necessary support for wasm-bindgen to use it!
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
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 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
Nowadays the compile times are mitigated with incremental compilation and
otherwise it's much more ergonomic to run only one test if they're all in the
same suite.
