* adding .vscode folder to .gitignore
* Adding view_mut_raw to generated arrays
* test populating rust vector from JS function
* Uint32Array test, need to make it generic
* Add doc + more test cases
* replacing macro-generated tests with generic test function
it is cleaner, safer and better that way
* improving rustdoc
This commit defaults all crates in-tree to use `std::future` by default
and none of them support the crates.io `futures` 0.1 crate any more.
This is a breaking change for `wasm-bindgen-futures` and
`wasm-bindgen-test` so they've both received a major version bump to
reflect the new defaults. Historical versions of these crates should
continue to work if necessary, but they won't receive any more
maintenance after this is merged.
The movement here liberally uses `async`/`await` to remove the need for
using any combinators on the `Future` trait. As a result many of the
crates now rely on a much more recent version of the compiler,
especially to run tests.
The `wasm-bindgen-futures` crate was updated to remove all of its
futures-related dependencies and purely use `std::future`, hopefully
improving its compatibility by not having any version compat
considerations over time. The implementations of the executors here are
relatively simple and only delve slightly into the `RawWaker` business
since there are no other stable APIs in `std::task` for wrapping these.
This commit also adds support for:
#[wasm_bindgen_test]
async fn foo() {
// ...
}
where previously you needed to pass `(async)` now that's inferred
because it's an `async fn`.
Closes#1558Closes#1695
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
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).
Now that functions and strings work properly with custom typechecks, these custom methods seem obsolete, so I'd recommend to use standard dyn_ref instead.
