* Get rid of the circular dependency when targeting ES modules
Fixes#3102Fixes#3149
I've changed the `*_bg.js` file to not import from the wasm module, eliminating the circular dependency between them.
It begins with an undefined `let wasm` which gets initialized by the user-facing JS file before calling `__wbindgen_start`, by calling an exported function `__wbg_set_wasm` that sets `wasm`.
* fmt
* Tweak formatting & update reference tests
Four years ago, we manually deprecated `BaseAudioContext` and
`AudioScheduledSourceNode` because Safari did not support them. The
stable version of Safari at the time was 12.0 (September 2018). The
current stable version of Safari is 16.1 (October 2022). Safari has
introduced support for `AudioScheduledSourceNode` in version 14.0
(September 2020), and `BaseAudioContext` in version 14.1 (April 2021).
* Call __destroy_into_raw everywhere a value is consumed
When using weak references the object needs to be unregistered from the
finalization registry when we pass it to a Rust method that takes in the
object by value. This wasn't happening, which meant that the finalizer
was called despite the object already being freed. For me this
manifested as a 'recursive use of an object detected which would lead to
unsafe aliasing in rust' exception.
* Add test that verifies we can cleanly GC
* Catch b.free exception so tests pass
* Fix typo
* Trigger warnings for unused wasm-bindgen attributes
This attempts to do something similar to #3070, but without potentially dangerous fallout from strict-mode failing on all the existing code out there.
Instead of forcing a compiler error like strict-mode does, this PR will internally generate unused variables with spans pointing to unused attributes, so that users get a relatively meaningful warning.
Here's how the result looks like on example from #2874:
```
warning: unused variable: `typescript_type`
--> tests\headless\snippets.rs:67:28
|
67 | #[wasm_bindgen(getter, typescript_type = "Thing[]")]
| ^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_typescript_type`
|
= note: `#[warn(unused_variables)]` on by default
```
This is not 100% perfect - until Rust has a built-in `compile_warning!`, nothing is - but is a better status quo than the current one and can help users find problematic attributes without actually breaking their builds.
Fixes#3038.
* Guide users who used the suggested (invalid) fix (#1)
Co-authored-by: Ingvar Stepanyan <me@rreverser.com>
* Deprecate strict-macro feature; update tests
* Skip anonymous scope if there are no unused attrs
* Fix unused-attr check for reserved attribute names
* Remove defunct deprecation warning
Co-authored-by: Lukas Lihotzki <lukas@lihotzki.de>
Adds a way to convert `JsValue` or a `BigInt` to `i64`/`u64`/`i128`/`u128` with type and range checks, returning the original `JsValue` otherwise.
This could be optimised a little bit further via more intrinsics, but it's good enough for the initial implementation, so leaving any optimisations for the future.
Fixes#2350.
FFI-safe enums via `#[repr(...)]` have been added couple of years ago, and by now there's no reason not to use them to represent an FFI-safe version of Option enum for our ABI.
* js-sys: Fix `BigInt::from(usize)` and `BigInt::from(isize)`
Fixes#3055
This changes `isize` and `usize` to be converted to `BigInt` in the same way as `i32`/`u32`, `BigInt(JsValue::from(n))`, rather than `JsValue::from(n).unchecked_into()`. The latter is now wrong since as of #2978 that `JsValue::from` returns a `Number`, not a `BigInt`.
* Add a regression test
* fmt
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).
Fixes#2272
Previously, checking if a value was an instance of a nonexistent type would result in an uncaught exception. This changes it to return `false` instead, avoiding having to do an extra feature-test of whether the type exists before calling `dyn_into`/`dyn_ref`/etc.
Makes it possible to use the newer `-> Result<(), E>` way of reporting test failures instead of just panicking in `#[wasm_bindgen_test]`, similarly to how you can do that in regular `#[test]`.
Resolves#2565.
* 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
Fixes#3042
Previously, any exported async functions which borrowed their arguments would fail to compile, because the values being referenced are stored on the stack of the initial synchronous call and then dropped, leaving nothing for the spawned future to reference.
This moves the referenced values into the spawned future, fixing that.
