* Use "legacy" instead of "stable" since `futures 0.1` is quicly
becoming "legacy"
* Rename "atomics" to "legacy_atomics" to leave room for the
libstd-based futures atomics version.
* Rename "polyfill" to "wait_async_polyfill" to specify what it's
polyfilling.
* Remove now-unneeded `State` enum
* Remove timeout argument from polyfill since we don't need it
* Call `Atomics.waitAsync` if it's available instead of using our polyfill
* Remove some extraneous dead code from the polyfill
* Add a `val: i32` argument to the polyfill
* Simplify the flow of futures with `Package` since `waitAsync` handles
all the heavy lifting for us.
* Remove `Arc<Package>` and just use `Package`
* Remove `RefCell` from inside of `Package` now that it is no longer
needed.
This fixes an issue also reported to upstream (rust-lang/rust#62628) to
ensure that we parse the `final` attribute as either `r#final` or
`final`, since now the compiler is giving us `r#final` and we were
previously only accepting `final`.
The parsing here was a bit wonky, but this setup ended up working!
After this change, any import that only takes and returns ABI-safe numbers (signed
integers less than 64 bits and unrestricted floating point numbers) will be a
direct import, and will not have a little JS shim in the middle.
We don't have a great mechanism for testing the generated bindings' contents --
as opposed to its behavior -- but I manually verified that everything here does
the Right Thing and doesn't have a JS shim:
```rust
\#[wasm_bindgen]
extern "C" {
fn trivial();
fn incoming_i32() -> i32;
fn incoming_f32() -> f32;
fn incoming_f64() -> f64;
fn outgoing_i32(x: i32);
fn outgoing_f32(y: f32);
fn outgoing_f64(z: f64);
fn many(x: i32, y: f32, z: f64) -> i32;
}
```
Furthermore, I verified that when our support for emitting native `anyref` is
enabled, then we do not have a JS shim for the following import, but if it is
disabled, then we do have a JS shim:
```rust
\#[wasm_bindgen]
extern "C" {
fn works_when_anyref_support_is_enabled(v: JsValue) -> JsValue;
}
```
Fixes#1636.
There are functions that are only used on wasm32 targets, but `cfg`ing them is
more work than just making the modules public, and this is just a testing crate.
JS engines guarantee that at least one of our `then` callbacks are
invoked, so that means if we destroy them prematurely they're guaranteed
to log an exception to the console! Instead to prevent exceptions from
happening tweak how the completion callbacks for JS futures are managed
and ensure that the closures stay alive until they're invoked later.
Closes#1637
Previously we always used `Function('return this')` but this triggers
CSP errors since it's basically `eval`. Instead this adds a few
preflight checks to look for objects like `globalThis`, `self`, etc.
Currently we don't have a `#[wasm_bindgen]` function annotation to
import a bare global field like `self`, but we test accesses with
`self.self` and `globalThis.globalThis`, catching errors to handle any
issues.
Closes#1641
