* guide: add missing and fix incorrect testing info
in the contributing section.
Some tests need `WASM_BINDGEN_SPLIT_LINKED_MODULES` set to run through,
and the macro ui-tests are not a workspace package anymore
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
* guide: improve macro test invocation
by using `-p wasm-bindgen-macro` instead of changing dir to `crates/macro`
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---------
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
* Make `wasm-bindgen` compatible with the standard C ABI
* Update the guide
* Fix reference tests
For some reason a couple of functions got switched around; no actual
meaningful changes.
* Add changelog entry
* Add spacing
* Mention `WasmAbi` in the changelog
* fix a tiny typo
* Enable passing String vectors and boxed slices across ABI
This is accomplished via conversion of the Strings to/from JsValues.
* Enable passing custom struct vectors over ABI
This was done by converting the structs to/from JsValues. It was
necessary to change the way relevant traits (e.g. WasmDescribe,
IntoWasmAbi etc.) are implemented. It's impossible to implement these
for `Box<[#name]>` in codegen.rs because implementing traits on generic
types is only allowed in the crate in which the trait is defined.
Naively adding a blanket implementation on the wasm-bindgen side doesn't
work either because it conflicts with the implementation for JsObjects.
The solution was to create traits like VectorIntoWasmAbi etc. that are
defined on the concrete type and contain the implementation for
IntoWasmAbi etc. for vectors of that type. JsObjects are blanket
implemented as before, and struct types are implemented in codegen.rs.
Due to the way these traits are defined, Rust requires implementing
types to be Sized, so they can't be used for the existing String
implementations.
Converting structs from JsValues was accomplished by adding an unwrap
function to the generated JavaScript class, and calling that from Rust.
* Remove unneeded require
* Move uses out of if_std
* Add documentation
* Move incorrect use statements
* Fix mistake in comment
* Throw on invalid array elements instead of silently removing them
I put some work into making sure that you can tell what function the error message is coming from. You still have to dig into the call stack of the error message to see it, but hopefully that's not too big an ask?
* Get rid of `JsValueVector`
The main reason for this, which I didn't mention before, is that I found it really confusing when I was originally reviewing this PR what the difference was between `JsValueVector` and `Vector{From,Into}WasmAbi`, since it really looks like another conversion trait at first glance.
* Respect the configured `wasm_bindgen` crate path
* Change the error type for String and rust structs' TryFrom<JsValue> impls to JsValue
* test string vecs too
* Refactor `String` impls
I moved the `TryFrom<JsValue>` impl out of convert/slices.rs, it doesn't
really belong there, and also got rid of the `js_value_vectors!` macro
in favour of just implementing it for `String` directly; there's not
much point in a macro you only use for one type.
* Don't require manual `OptionVector{From,Into}WasmAbi` impls
I noticed that strings and rust structs weren't implementing
`OptionVectorFromWasmAbi`, so I tried to make a failing test and... it
worked.
That threw me for a loop for a bit until I realised that it was because
I'd used `Vec<T>`, and `Vec<T>`'s impls of `Option{From,Into}WasmAbi`
didn't actually rely on `Box<[T]>` implementing the traits: they just
required that it implemented `{From,Into}WasmAbi` with an ABI of
`WasmSlice`, since from there the element type doesn't matter. So then
I thought 'well, why not do that for `Box<[T]>` too?
so that's how this commit's pile of new tests came to be.
* fix clippy
* Fix generated typescript
Since vecs of strings and rust structs were describing themselves as `Box<[JsValue]>`, they got typed as such - as `any[]`. This fixes that by using `NAMED_EXTERNREF` instead of just plain `EXTERNREF` with the type we want.
This is maybe _slightly_ sketchy, since `NAMED_EXTERNREF` is meant for imported JS types, but ehhh it's fine. You can already put arbitrary TypeScript in there with `typescript_type`.
* reorder some impls
This is the nitpickiest of nitpicks, but this is my PR goddammit and I can do what I want :)
* Update schema hash
I didn't actually bump the schema version because it didn't change. If you don't use the `TryFrom<JsValue>` impl for Rust structs (or pass a `Vec` of them from JS to Rust), using an old CLI version will work fine; if you do though, you get a bit of a cryptic error message:
```
error: import of `__wbg_foo_unwrap` doesn't have an adapter listed
```
(That's from trying to pass a `Vec<Foo>` from JS to Rust.)
So idk, maybe that's worth bumping the schema version over anyway?
* undo some unnecessary refactors
* don't pointlessly use assert.deepStrictEqual for numbers
* Update the guide
* update reference tests
* add WASI check
* Extremely nitpicky tweaks
---------
Co-authored-by: Billy Bradley <billy@squeno.com>
Co-authored-by: Billy Bradley <billy.jack.bradley@gmail.com>
* Remove class wrap for constructors in Rust exports
After #1594 constructors of Rust exported structs started using class
wrapping when generating JS shims. Wrapping erases prototype information
from the object instance in JS and as a result it is not possible to
override methods (via inheritance) of the generated class.
Additionally, some checks to ensure constructors always return an
instance of `Self` were lost.
This PR is rebased from #3561, it passes the constructor information
from the `Builder` into the instruction translation function which
is then used to modify the generated bindings.
The `return` statement is also removed instead the value is directly
attached to the instance.
Signed-off-by: Oliver T <geronimooliver00@gmail.com>
* Fix typo
Co-authored-by: Liam Murphy <liampm32@gmail.com>
* Disallow returning JS primitives from constructors
Signed-off-by: Oliver T <geronimooliver00@gmail.com>
* Added missing String in match
Signed-off-by: Oliver T <geronimooliver00@gmail.com>
* Handle nested descriptors
Signed-off-by: Oliver T <geronimooliver00@gmail.com>
---------
Signed-off-by: Oliver T <geronimooliver00@gmail.com>
Co-authored-by: Liam Murphy <liampm32@gmail.com>
There were several pages that had been added to the guide, but were inaccessible due to not being listed in `SUMMARY.md` (which is how you specify the layout for the left sidebar). This PR fixes that.
I also noticed that there were two pages for the same `typscript_type` attribute: one in the 'on JS imports' section (which was inaccessible) and one in the 'on Rust exports' section. These aren't for two different versions of the attribute; they're both for the same attribute which can only be applied to JS imports.
The one in the 'on JS imports' section was much less detailed, so I got rid of it and moved the other one into its place.
Closes#2426 (an issue that was opened ages ago about the `typescript_type` page being in the wrong section). There was a bit of discussion there about whether it does actually belong in the 'on Rust exports' section, since despite being directly applied to JS imports its usage is to change the TypeScript output for Rust exports, but I think that the site where it's applied is more important.
* Running tests on workers without displaying errors
* Initializing the wasm bindgen only in worker
* Adding tests to run in workers
* Format
* Adding webdriver.json file
* Removed memory module from worker tests
* Keeping original JsValue without overwriting
* Updated the documentation
* Add support for specifying a default `js_namespace` on an `extern "C" { … }` block
* Improve wording in `js_namespace` section of guide
Co-authored-by: Liam Murphy <liampm32@gmail.com>
---------
Co-authored-by: Liam Murphy <liampm32@gmail.com>
The start function still gets called on every thread in that example because it doesn't actually use wasm multithreading; each thread's instance has it's own separate memory pool and is completely unaware of the other thread. So, attempting to switch it to use a regular start function caused the worker thread to spawn another one, which does likewise, quickly spiralling out of control.
It also ended up panicking because, thinking it was the main thread, the code was trying to access `window` inside of a worker.
Resolves#1004#2710 added support for returning `Result<T, impl Into<JsValue>>` rather than just `Result<T, JsValue>`, but the `wasm-bindgen` guide still claims that only the latter is supported.
This fixes that, and also fixes a mistake in the table for what forms `Result` can be returned in (it previously claimed that only `Option<Result<...>>` was supported, when in fact only a plain `Result<...>` is supported).
* Deprecate `JsValue::from_serde` and `JsValue::into_serde`
I've listed `serde-wasm-bindgen` as the replacement, and changed the section of the guide that talks about Serde to talk about `serde-wasm-bindgen` instead of the deprecated methods.
I didn't remove it entirely because I can imagine someone remembering it and trying to look it back up, only to find that it no longer exists, which would quite frustrating. I also added a footnote about the deprecated methods in case someone remembers the old way and wants to know what happened.
There were several examples using `from_serde`/`into_serde`, which I updated to use `serde-wasm-bindgen` or not use `serde` altogether.
The `fetch` example was a bit weird, in that it took a JS value, parsed it into a Rust value, only to serialize it back into a JS value. I removed that entirely in favour of just passing the original JS value directly. I suppose it behaves slightly differently in that it loses the extra validation, but a panic isn't all that much better than a JS runtime error.
* fmt
* Mention JSON as an alternative to `serde-wasm-bindgen`
* Use `gloo-utils` instead of raw `JSON`
I was considering leaving the examples using `JSON` directly and mentioning `gloo-utils` as an aside, but that has the major footgun that `JSON.stringify(undefined) === undefined`, causing a panic when deserializing `undefined` since the return type of `JSON::stringify` isn't optional. `gloo-utils` works around this, so I recommended it instead.
* Mention `gloo-utils` in API docs
* Rephrase section about deprecated methods
