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).
Constructing boxed primitives was deprecated in #1447.
Some tests have been still using these methods, so this PR either updates them to use newly added {primitive}::from implementations or adds `#[allow(deprecated)]` where necessary.
Treats any object of shape `{ next: function }` as an iterator via new `is_type_of` method. This is consistent with JavaScript iteration protocol which we already respect.
Also fixes a minor issue that `is_function` was unnecessarily called twice (once explicitly and once as part of `dyn_into` which now does the same check).
This commit adds `#[derive(PartialEq, Eq)]` to many types throughout
`js-sys`. These types are basically all based on `Object`, which means
that `Object.is` can be used for `PartialEq` and the `Eq` requirements
are upheld.
The macro has also been updated to internally store the deref target
instead of unconditionally storing `JsValue`, allowing `#[derive]` to
work a bit better in these situations.
* Ensure `PartialEq` is implemented from these types to native Rust types
* Implement `From` between these type and native Rust types
* Deprecated `Number::new` and `Boolean::new` to discourage use of the
object forms, recommending the `from` constructors instead.
Closes#1446
This commit aims to address #1348 via a number of strategies:
* Documentation is updated to warn about UTF-16 vs UTF-8 problems
between JS and Rust. Notably documenting that `as_string` and handling
of arguments is lossy when there are lone surrogates.
* A `JsString::is_valid_utf16` method was added to test whether
`as_string` is lossless or not.
The intention is that most default behavior of `wasm-bindgen` will
remain, but where necessary bindings will use `JsString` instead of
`str`/`String` and will manually check for `is_valid_utf16` as
necessary. It's also hypothesized that this is relatively rare and not
too performance critical, so an optimized intrinsic for `is_valid_utf16`
is not yet provided.
Closes#1348
Most of the CLI crates were already in the 2018 edition, and it turns
out that one of the macro crates was already in the 2018 edition so we
may as well move everything to the 2018 edition!
Always nice to remove those `extern crate` statements nowadays!
This commit also does a `cargo fmt --all` to make sure we're conforming
with style again.
This allows to significantly speed up iteration over small collections, where string encoding is the primary overhead.
Related to #1386, but works around only this partial case.
This commit adds experimental support to `wasm-bindgen` to emit and
leverage the `anyref` native wasm type. This native type is still in a
proposal status (the reference-types proposal). The intention of
`anyref` is to be able to directly hold JS values in wasm and pass the
to imported functions, namely to empower eventual host bindings (now
renamed WebIDL bindings) integration where we can skip JS shims
altogether for many imports.
This commit doesn't actually affect wasm-bindgen's behavior at all
as-is, but rather this support requires an opt-in env var to be
configured. Once the support is stable in browsers it's intended that
this will add a CLI switch for turning on this support, eventually
defaulting it to `true` in the far future.
The basic strategy here is to take the `stack` and `slab` globals in the
generated JS glue and move them into wasm using a table. This new table
in wasm is managed at the fringes via injected shims. At
`wasm-bindgen`-time the CLI will rewrite exports and imports with shims
that actually use `anyref` if needed, performing loads/stores inside the
wasm module instead of externally in the wasm module.
This should provide a boost over what we have today, but it's not a
fantastic strategy long term. We have a more grand vision for `anyref`
being a first-class type in the language, but that's on a much longer
horizon and this is currently thought to be the best we can do in terms
of integration in the near future.
The stack/heap JS tables are combined into one wasm table. The stack
starts at the end of the table and grows down with a stack pointer (also
injected). The heap starts at the end and grows up (state managed in
linear memory). The anyref transformation here will hook up various
intrinsics in wasm-bindgen to the runtime functionality if the anyref
supoprt is enabled.
The main tricky treatment here was applied to closures, where we need JS
to use a different function pointer than the one Rust gives it to use a
JS function pointer empowered with anyref. This works by switching up a
bit how descriptors work, embedding the shims to call inside descriptors
rather than communicated at runtime. This means that we're accessing
constant values in the generated JS and we can just update the constant
value accessed.
