wasm-bindgen/src/lib.rs

1122 lines
32 KiB
Rust
Raw Normal View History

//! Runtime support for the `wasm-bindgen` tool
//!
//! This crate contains the runtime support necessary for `wasm-bindgen` the
//! attribute and tool. Crates pull in the `#[wasm_bindgen]` attribute through
//! this crate and this crate also provides JS bindings through the `JsValue`
//! interface.
#![no_std]
#![doc(html_root_url = "https://docs.rs/wasm-bindgen/0.2")]
#![cfg_attr(feature = "nightly", feature(unsize))]
2017-12-14 19:31:01 -08:00
2018-07-05 20:14:38 -07:00
use core::fmt;
use core::marker;
use core::mem;
use core::ops::{Deref, DerefMut};
use crate::convert::FromWasmAbi;
macro_rules! if_std {
($($i:item)*) => ($(
#[cfg(feature = "std")] $i
)*)
}
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
macro_rules! externs {
($(#[$attr:meta])* extern "C" { $(fn $name:ident($($args:tt)*) -> $ret:ty;)* }) => (
#[cfg(all(target_arch = "wasm32", not(target_os = "emscripten")))]
$(#[$attr])*
extern "C" {
$(fn $name($($args)*) -> $ret;)*
}
$(
#[cfg(not(all(target_arch = "wasm32", not(target_os = "emscripten"))))]
#[allow(unused_variables)]
unsafe extern fn $name($($args)*) -> $ret {
panic!("function not implemented on non-wasm32 targets")
}
)*
)
}
/// A module which is typically glob imported from:
///
/// ```
/// use wasm_bindgen::prelude::*;
/// ```
2017-12-14 19:31:01 -08:00
pub mod prelude {
pub use crate::JsValue;
pub use crate::UnwrapThrowExt;
#[doc(hidden)]
pub use wasm_bindgen_macro::__wasm_bindgen_class_marker;
pub use wasm_bindgen_macro::wasm_bindgen;
if_std! {
pub use crate::closure::Closure;
}
2017-12-14 19:31:01 -08:00
}
pub mod convert;
Overhaul how type information gets to the CLI This commit is a complete overhaul of how the `#[wasm_bindgen]` macro communicates type information to the CLI tool, and it's done in a somewhat... unconventional fashion. Today we've got a problem where the generated JS needs to understand the types of each function exported or imported. This understanding is what enables it to generate the appropriate JS wrappers and such. We want to, however, be quite flexible and extensible in types that are supported across the boundary, which means that internally we rely on the trait system to resolve what's what. Communicating the type information historically was done by creating a four byte "descriptor" and using associated type projections to communicate that to the CLI tool. Unfortunately four bytes isn't a lot of space to cram information like arguments to a generic function, tuple types, etc. In general this just wasn't flexible enough and the way custom references were treated was also already a bit of a hack. This commit takes a radical step of creating a **descriptor function** for each function imported/exported. The really crazy part is that the `wasm-bindgen` CLI tool now embeds a wasm interpreter and executes these functions when the CLI tool is invoked. By allowing arbitrary functions to get executed it's now *much* easier to inform `wasm-bindgen` about complicated structures of types. Rest assured though that all these descriptor functions are automatically unexported and gc'd away, so this should not have any impact on binary sizes A new internal trait, `WasmDescribe`, is added to represent a description of all types, sort of like a serialization of the structure of a type that `wasm-bindgen` can understand. This works by calling a special exported function with a `u32` value a bunch of times. This means that when we run a descriptor we effectively get a `Vec<u32>` in the `wasm-bindgen` CLI tool. This list of integers can then be parsed into a rich `enum` for the JS generation to work with. This commit currently only retains feature parity with the previous implementation. I hope to soon solve issues like #123, #104, and #111 with this support.
2018-04-13 07:33:46 -07:00
pub mod describe;
mod cast;
pub use crate::cast::JsCast;
if_std! {
extern crate std;
use std::prelude::v1::*;
pub mod closure;
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
mod anyref;
}
/// Representation of an object owned by JS.
///
/// A `JsValue` doesn't actually live in Rust right now but actually in a table
/// owned by the `wasm-bindgen` generated JS glue code. Eventually the ownership
/// will transfer into wasm directly and this will likely become more efficient,
/// but for now it may be slightly slow.
pub struct JsValue {
2017-12-14 19:31:01 -08:00
idx: u32,
_marker: marker::PhantomData<*mut u8>, // not at all threadsafe
2017-12-14 19:31:01 -08:00
}
const JSIDX_OFFSET: u32 = 32; // keep in sync with js/mod.rs
const JSIDX_UNDEFINED: u32 = JSIDX_OFFSET + 0;
const JSIDX_NULL: u32 = JSIDX_OFFSET + 1;
const JSIDX_TRUE: u32 = JSIDX_OFFSET + 2;
const JSIDX_FALSE: u32 = JSIDX_OFFSET + 3;
const JSIDX_RESERVED: u32 = JSIDX_OFFSET + 4;
impl JsValue {
/// The `null` JS value constant.
pub const NULL: JsValue = JsValue {
idx: JSIDX_NULL,
_marker: marker::PhantomData,
};
/// The `undefined` JS value constant.
2018-06-27 22:42:34 -07:00
pub const UNDEFINED: JsValue = JsValue {
idx: JSIDX_UNDEFINED,
_marker: marker::PhantomData,
2018-06-27 22:42:34 -07:00
};
/// The `true` JS value constant.
pub const TRUE: JsValue = JsValue {
idx: JSIDX_TRUE,
_marker: marker::PhantomData,
};
/// The `false` JS value constant.
pub const FALSE: JsValue = JsValue {
idx: JSIDX_FALSE,
_marker: marker::PhantomData,
};
#[inline]
fn _new(idx: u32) -> JsValue {
JsValue {
idx,
_marker: marker::PhantomData,
}
}
/// Creates a new JS value which is a string.
///
/// The utf-8 string provided is copied to the JS heap and the string will
/// be owned by the JS garbage collector.
#[inline]
pub fn from_str(s: &str) -> JsValue {
2018-11-27 12:07:59 -08:00
unsafe { JsValue::_new(__wbindgen_string_new(s.as_ptr(), s.len())) }
}
/// Creates a new JS value which is a number.
///
/// This function creates a JS value representing a number (a heap
/// allocated number) and returns a handle to the JS version of it.
#[inline]
pub fn from_f64(n: f64) -> JsValue {
2018-11-27 12:07:59 -08:00
unsafe { JsValue::_new(__wbindgen_number_new(n)) }
}
/// Creates a new JS value which is a boolean.
///
/// This function creates a JS object representing a boolean (a heap
/// allocated boolean) and returns a handle to the JS version of it.
#[inline]
pub fn from_bool(b: bool) -> JsValue {
2018-11-27 12:07:59 -08:00
if b {
JsValue::TRUE
} else {
JsValue::FALSE
}
}
/// Creates a new JS value representing `undefined`.
#[inline]
pub fn undefined() -> JsValue {
JsValue::UNDEFINED
}
/// Creates a new JS value representing `null`.
#[inline]
pub fn null() -> JsValue {
JsValue::NULL
}
/// Creates a new JS symbol with the optional description specified.
///
/// This function will invoke the `Symbol` constructor in JS and return the
/// JS object corresponding to the symbol created.
pub fn symbol(description: Option<&str>) -> JsValue {
unsafe {
match description {
Some(description) => JsValue::_new(__wbindgen_symbol_named_new(
description.as_ptr(),
description.len(),
)),
None => JsValue::_new(__wbindgen_symbol_anonymous_new()),
}
}
}
/// Creates a new `JsValue` from the JSON serialization of the object `t`
/// provided.
///
/// This function will serialize the provided value `t` to a JSON string,
/// send the JSON string to JS, parse it into a JS object, and then return
/// a handle to the JS object. This is unlikely to be super speedy so it's
/// not recommended for large payloads, but it's a nice to have in some
/// situations!
///
/// Usage of this API requires activating the `serde-serialize` feature of
/// the `wasm-bindgen` crate.
///
/// # Errors
///
/// Returns any error encountered when serializing `T` into JSON.
#[cfg(feature = "serde-serialize")]
pub fn from_serde<T>(t: &T) -> serde_json::Result<JsValue>
2018-06-27 22:42:34 -07:00
where
T: serde::ser::Serialize + ?Sized,
{
let s = serde_json::to_string(t)?;
2018-11-27 12:07:59 -08:00
unsafe { Ok(JsValue::_new(__wbindgen_json_parse(s.as_ptr(), s.len()))) }
}
/// Invokes `JSON.stringify` on this value and then parses the resulting
/// JSON into an arbitrary Rust value.
///
/// This function will first call `JSON.stringify` on the `JsValue` itself.
/// The resulting string is then passed into Rust which then parses it as
/// JSON into the resulting value.
///
/// Usage of this API requires activating the `serde-serialize` feature of
/// the `wasm-bindgen` crate.
///
/// # Errors
///
/// Returns any error encountered when parsing the JSON into a `T`.
#[cfg(feature = "serde-serialize")]
pub fn into_serde<T>(&self) -> serde_json::Result<T>
2018-06-27 22:42:34 -07:00
where
T: for<'a> serde::de::Deserialize<'a>,
{
2019-01-10 23:37:12 +00:00
unsafe {
First refactor for WebIDL bindings This commit starts the `wasm-bindgen` CLI tool down the road to being a true polyfill for WebIDL bindings. This refactor is probably the first of a few, but is hopefully the largest and most sprawling and everything will be a bit more targeted from here on out. The goal of this refactoring is to separate out the massive `crates/cli-support/src/js/mod.rs` into a number of separate pieces of functionality. It currently takes care of basically everything including: * Binding intrinsics * Handling anyref transformations * Generating all JS for imports/exports * All the logic for how to import and how to name imports * Execution and management of wasm-bindgen closures Many of these are separable concerns and most overlap with WebIDL bindings. The internal refactoring here is intended to make it more clear who's responsible for what as well as making some existing operations much more straightforward. At a high-level, the following changes are done: 1. A `src/webidl.rs` module is introduced. The purpose of this module is to take all of the raw wasm-bindgen custom sections from the module and transform them into a WebIDL bindings section. This module has a placeholder `WebidlCustomSection` which is nowhere near the actual custom section but if you squint is in theory very similar. It's hoped that this will eventually become the true WebIDL custom section, currently being developed in an external crate. Currently, however, the WebIDL bindings custom section only covers a subset of the functionality we export to wasm-bindgen users. To avoid leaving them high and dry this module also contains an auxiliary custom section named `WasmBindgenAux`. This custom section isn't intended to have a binary format, but is intended to represent a theoretical custom section necessary to couple with WebIDL bindings to achieve all our desired functionality in `wasm-bindgen`. It'll never be standardized, but it'll also never be serialized :) 2. The `src/webidl.rs` module now takes over quite a bit of functionality from `src/js/mod.rs`. Namely it handles synthesis of an `export_map` and an `import_map` mapping export/import IDs to exactly what's expected to be hooked up there. This does not include type information (as that's in the bindings section) but rather includes things like "this is the method of class A" or "this import is from module `foo`" and things like that. These could arguably be subsumed by future JS features as well, but that's for another time! 3. All handling of wasm-bindgen "descriptor functions" now happens in a dedicated `src/descriptors.rs` module. The output of this module is its own custom section (intended to be immediately consumed by the WebIDL module) which is in theory what we want to ourselves emit one day but rustc isn't capable of doing so right now. 4. Invocations and generations of imports are completely overhauled. Using the `import_map` generated in the WebIDL step all imports are now handled much more precisely in one location rather than haphazardly throughout the module. This means we have precise information about each import of the module and we only modify exactly what we're looking at. This also vastly simplifies intrinsic generation since it's all simply a codegen part of the `rust2js.rs` module now. 5. Handling of direct imports which don't have a JS shim generated is slightly different from before and is intended to be future-compatible with WebIDL bindings in its full glory, but we'll need to update it to handle cases for constructors and method calls eventually as well. 6. Intrinsic definitions now live in their own file (`src/intrinsic.rs`) and have a separated definition for their symbol name and signature. The actual implementation of each intrinsic lives in `rust2js.rs` There's a number of TODO items to finish before this merges. This includes reimplementing the anyref pass and actually implementing import maps for other targets. Those will come soon in follow-up commits, but the entire `tests/wasm/main.rs` suite is currently passing and this seems like a good checkpoint.
2019-05-23 09:15:26 -07:00
let mut ret = [0usize; 2];
__wbindgen_json_serialize(&mut ret, self.idx);
let s = Vec::from_raw_parts(ret[0] as *mut u8, ret[1], ret[1]);
2019-01-10 23:37:12 +00:00
let s = String::from_utf8_unchecked(s);
serde_json::from_str(&s)
}
}
/// Returns the `f64` value of this JS value if it's an instance of a
/// number.
///
/// If this JS value is not an instance of a number then this returns
/// `None`.
pub fn as_f64(&self) -> Option<f64> {
let mut invalid = 0;
unsafe {
let ret = __wbindgen_number_get(self.idx, &mut invalid);
if invalid == 1 {
None
} else {
Some(ret)
}
}
}
Create the `web-sys` crate mechanically from WebIDL (#409) * Create a new `web-sys` crate This will eventually contain all the WebIDL-generated bindings to Web APIs. * ci: Test the new `web-sys` crate in CI * web-sys: Add a small README * web-sys: Vendor all the WebIDL files from mozilla-central * backend: Add a pass to remove AST items that use undefined imports This is necessary for the WebIDL frontend, which can't translate many WebIDL constructs into equivalent wasm-bindgen AST things yet. It lets us make incremental progress: we can generate bindings to methods we can support right now even though there might be methods on the same interface that we can't support yet. * webidl: Add a bunch of missing semicolons * webidl: Make parsing private It was only `pub` so that we could test it, but we ended up moving towards integration tests rather than unit tests that assert particular ASTs are parsed from WebIDL files. * webidl: Remove uses of undefined import types * test-project-builder: Build projects in "very verbose" mode This helps for debugging failing WebIDL-related tests. * test-project-builder: Add more profiling timers * test-project-builder: Detect when webpack-dev-server fails Instead of going into an infinite loop, detect when webpack-dev-server fails to start up and early exit the test. * webidl: Specify version for dev-dependency on wasm-bindgen-backend Instead of only a relative path. * guide: Add section about contributing to `web-sys` * WIP enable Event.webidl Still need to fix and finish the test. * Update expected webidl output * Start out a test's status as incomplete That way if we don't fill it in the error message doesn't look quite so bizarre * Fix onerror function in headless mode Otherwise we don't see any output! * Fix package.json/node_modules handling in project generation Make sure these are looked up in the git project root rather than the crate root * Avoid logging body text This was meant for debugging and is otherwise pretty noisy * Fix a relative path * More expected test fixes * Fix a typo * test-project-builder: Allow asynchronous tests * webidl: Convert [Unforgeable] attributes into `#[wasm_bindgen(structural)]` Fixes #432 * test-project-builder: Print generated WebIDL bindings for debugging purposes Helps debug bad WebIDL bindings generation inside tests. * When we can't find a descriptor, say which one can't be found This helps when debugging things that need to become structural. * web-sys: Test bindings for Event * ci: Use `--manifest-path dir` instead of `cd dir && ...` * web-sys: Just move .webidl files isntead of symlinking to enable them * tests: Polyfill Array.prototype.values for older browsers in CI * test-project-builder: Don't panic on poisoned headless test mutex We only use it to serialize headless tests so that we don't try to bind the port concurrently. Its OK to run another headless test if an earlier one panicked. * JsValue: Add {is,as}_{object,function} methods Allows dynamically casting values to `js::Object` and `js::Function`. * tidy: Fix whitespace and missing semicolons * Allow for dynamic feature detection of methods If we create bindings to a method that doesn't exist in this implementation, then it shouldn't fail until if/when we actually try and invoke that missing method. * tests: Do feature detection in Array.prototype.values test * Add JsValue::{is_string, as_js_string} methods And document all the cast/convert/check methods for js value. * eslint: allow backtick string literals * Only generate a fallback import function for non-structural imports
2018-07-09 16:35:25 -07:00
/// Tests whether this JS value is a JS string.
pub fn is_string(&self) -> bool {
unsafe { __wbindgen_is_string(self.idx) == 1 }
}
/// If this JS value is a string value, this function copies the JS string
/// value into wasm linear memory, encoded as UTF-8, and returns it as a
/// Rust `String`.
///
2018-11-09 13:12:16 +01:00
/// To avoid the copying and re-encoding, consider the
/// `JsString::try_from()` function from [js-sys](https://docs.rs/js-sys)
/// instead.
///
/// If this JS value is not an instance of a string or if it's not valid
/// utf-8 then this returns `None`.
///
/// # UTF-16 vs UTF-8
///
/// JavaScript strings in general are encoded as UTF-16, but Rust strings
/// are encoded as UTF-8. This can cause the Rust string to look a bit
/// different than the JS string sometimes. For more details see the
/// [documentation about the `str` type][caveats] which contains a few
/// caveats about the encodings.
///
/// [caveats]: https://rustwasm.github.io/docs/wasm-bindgen/reference/types/str.html
#[cfg(feature = "std")]
pub fn as_string(&self) -> Option<String> {
unsafe {
let mut len = 0;
let ptr = __wbindgen_string_get(self.idx, &mut len);
if ptr.is_null() {
None
} else {
let data = Vec::from_raw_parts(ptr, len, len);
Some(String::from_utf8_unchecked(data))
}
}
}
/// Returns the `bool` value of this JS value if it's an instance of a
/// boolean.
///
/// If this JS value is not an instance of a boolean then this returns
/// `None`.
pub fn as_bool(&self) -> Option<bool> {
unsafe {
match __wbindgen_boolean_get(self.idx) {
0 => Some(false),
1 => Some(true),
_ => None,
}
}
}
/// Tests whether this JS value is `null`
#[inline]
pub fn is_null(&self) -> bool {
2018-06-27 22:42:34 -07:00
unsafe { __wbindgen_is_null(self.idx) == 1 }
}
/// Tests whether this JS value is `undefined`
#[inline]
pub fn is_undefined(&self) -> bool {
2018-06-27 22:42:34 -07:00
unsafe { __wbindgen_is_undefined(self.idx) == 1 }
}
/// Tests whether the type of this JS value is `symbol`
#[inline]
pub fn is_symbol(&self) -> bool {
2018-06-27 22:42:34 -07:00
unsafe { __wbindgen_is_symbol(self.idx) == 1 }
}
Create the `web-sys` crate mechanically from WebIDL (#409) * Create a new `web-sys` crate This will eventually contain all the WebIDL-generated bindings to Web APIs. * ci: Test the new `web-sys` crate in CI * web-sys: Add a small README * web-sys: Vendor all the WebIDL files from mozilla-central * backend: Add a pass to remove AST items that use undefined imports This is necessary for the WebIDL frontend, which can't translate many WebIDL constructs into equivalent wasm-bindgen AST things yet. It lets us make incremental progress: we can generate bindings to methods we can support right now even though there might be methods on the same interface that we can't support yet. * webidl: Add a bunch of missing semicolons * webidl: Make parsing private It was only `pub` so that we could test it, but we ended up moving towards integration tests rather than unit tests that assert particular ASTs are parsed from WebIDL files. * webidl: Remove uses of undefined import types * test-project-builder: Build projects in "very verbose" mode This helps for debugging failing WebIDL-related tests. * test-project-builder: Add more profiling timers * test-project-builder: Detect when webpack-dev-server fails Instead of going into an infinite loop, detect when webpack-dev-server fails to start up and early exit the test. * webidl: Specify version for dev-dependency on wasm-bindgen-backend Instead of only a relative path. * guide: Add section about contributing to `web-sys` * WIP enable Event.webidl Still need to fix and finish the test. * Update expected webidl output * Start out a test's status as incomplete That way if we don't fill it in the error message doesn't look quite so bizarre * Fix onerror function in headless mode Otherwise we don't see any output! * Fix package.json/node_modules handling in project generation Make sure these are looked up in the git project root rather than the crate root * Avoid logging body text This was meant for debugging and is otherwise pretty noisy * Fix a relative path * More expected test fixes * Fix a typo * test-project-builder: Allow asynchronous tests * webidl: Convert [Unforgeable] attributes into `#[wasm_bindgen(structural)]` Fixes #432 * test-project-builder: Print generated WebIDL bindings for debugging purposes Helps debug bad WebIDL bindings generation inside tests. * When we can't find a descriptor, say which one can't be found This helps when debugging things that need to become structural. * web-sys: Test bindings for Event * ci: Use `--manifest-path dir` instead of `cd dir && ...` * web-sys: Just move .webidl files isntead of symlinking to enable them * tests: Polyfill Array.prototype.values for older browsers in CI * test-project-builder: Don't panic on poisoned headless test mutex We only use it to serialize headless tests so that we don't try to bind the port concurrently. Its OK to run another headless test if an earlier one panicked. * JsValue: Add {is,as}_{object,function} methods Allows dynamically casting values to `js::Object` and `js::Function`. * tidy: Fix whitespace and missing semicolons * Allow for dynamic feature detection of methods If we create bindings to a method that doesn't exist in this implementation, then it shouldn't fail until if/when we actually try and invoke that missing method. * tests: Do feature detection in Array.prototype.values test * Add JsValue::{is_string, as_js_string} methods And document all the cast/convert/check methods for js value. * eslint: allow backtick string literals * Only generate a fallback import function for non-structural imports
2018-07-09 16:35:25 -07:00
/// Tests whether `typeof self == "object" && self !== null`.
#[inline]
Create the `web-sys` crate mechanically from WebIDL (#409) * Create a new `web-sys` crate This will eventually contain all the WebIDL-generated bindings to Web APIs. * ci: Test the new `web-sys` crate in CI * web-sys: Add a small README * web-sys: Vendor all the WebIDL files from mozilla-central * backend: Add a pass to remove AST items that use undefined imports This is necessary for the WebIDL frontend, which can't translate many WebIDL constructs into equivalent wasm-bindgen AST things yet. It lets us make incremental progress: we can generate bindings to methods we can support right now even though there might be methods on the same interface that we can't support yet. * webidl: Add a bunch of missing semicolons * webidl: Make parsing private It was only `pub` so that we could test it, but we ended up moving towards integration tests rather than unit tests that assert particular ASTs are parsed from WebIDL files. * webidl: Remove uses of undefined import types * test-project-builder: Build projects in "very verbose" mode This helps for debugging failing WebIDL-related tests. * test-project-builder: Add more profiling timers * test-project-builder: Detect when webpack-dev-server fails Instead of going into an infinite loop, detect when webpack-dev-server fails to start up and early exit the test. * webidl: Specify version for dev-dependency on wasm-bindgen-backend Instead of only a relative path. * guide: Add section about contributing to `web-sys` * WIP enable Event.webidl Still need to fix and finish the test. * Update expected webidl output * Start out a test's status as incomplete That way if we don't fill it in the error message doesn't look quite so bizarre * Fix onerror function in headless mode Otherwise we don't see any output! * Fix package.json/node_modules handling in project generation Make sure these are looked up in the git project root rather than the crate root * Avoid logging body text This was meant for debugging and is otherwise pretty noisy * Fix a relative path * More expected test fixes * Fix a typo * test-project-builder: Allow asynchronous tests * webidl: Convert [Unforgeable] attributes into `#[wasm_bindgen(structural)]` Fixes #432 * test-project-builder: Print generated WebIDL bindings for debugging purposes Helps debug bad WebIDL bindings generation inside tests. * When we can't find a descriptor, say which one can't be found This helps when debugging things that need to become structural. * web-sys: Test bindings for Event * ci: Use `--manifest-path dir` instead of `cd dir && ...` * web-sys: Just move .webidl files isntead of symlinking to enable them * tests: Polyfill Array.prototype.values for older browsers in CI * test-project-builder: Don't panic on poisoned headless test mutex We only use it to serialize headless tests so that we don't try to bind the port concurrently. Its OK to run another headless test if an earlier one panicked. * JsValue: Add {is,as}_{object,function} methods Allows dynamically casting values to `js::Object` and `js::Function`. * tidy: Fix whitespace and missing semicolons * Allow for dynamic feature detection of methods If we create bindings to a method that doesn't exist in this implementation, then it shouldn't fail until if/when we actually try and invoke that missing method. * tests: Do feature detection in Array.prototype.values test * Add JsValue::{is_string, as_js_string} methods And document all the cast/convert/check methods for js value. * eslint: allow backtick string literals * Only generate a fallback import function for non-structural imports
2018-07-09 16:35:25 -07:00
pub fn is_object(&self) -> bool {
unsafe { __wbindgen_is_object(self.idx) == 1 }
}
/// Tests whether the type of this JS value is `function`.
#[inline]
Create the `web-sys` crate mechanically from WebIDL (#409) * Create a new `web-sys` crate This will eventually contain all the WebIDL-generated bindings to Web APIs. * ci: Test the new `web-sys` crate in CI * web-sys: Add a small README * web-sys: Vendor all the WebIDL files from mozilla-central * backend: Add a pass to remove AST items that use undefined imports This is necessary for the WebIDL frontend, which can't translate many WebIDL constructs into equivalent wasm-bindgen AST things yet. It lets us make incremental progress: we can generate bindings to methods we can support right now even though there might be methods on the same interface that we can't support yet. * webidl: Add a bunch of missing semicolons * webidl: Make parsing private It was only `pub` so that we could test it, but we ended up moving towards integration tests rather than unit tests that assert particular ASTs are parsed from WebIDL files. * webidl: Remove uses of undefined import types * test-project-builder: Build projects in "very verbose" mode This helps for debugging failing WebIDL-related tests. * test-project-builder: Add more profiling timers * test-project-builder: Detect when webpack-dev-server fails Instead of going into an infinite loop, detect when webpack-dev-server fails to start up and early exit the test. * webidl: Specify version for dev-dependency on wasm-bindgen-backend Instead of only a relative path. * guide: Add section about contributing to `web-sys` * WIP enable Event.webidl Still need to fix and finish the test. * Update expected webidl output * Start out a test's status as incomplete That way if we don't fill it in the error message doesn't look quite so bizarre * Fix onerror function in headless mode Otherwise we don't see any output! * Fix package.json/node_modules handling in project generation Make sure these are looked up in the git project root rather than the crate root * Avoid logging body text This was meant for debugging and is otherwise pretty noisy * Fix a relative path * More expected test fixes * Fix a typo * test-project-builder: Allow asynchronous tests * webidl: Convert [Unforgeable] attributes into `#[wasm_bindgen(structural)]` Fixes #432 * test-project-builder: Print generated WebIDL bindings for debugging purposes Helps debug bad WebIDL bindings generation inside tests. * When we can't find a descriptor, say which one can't be found This helps when debugging things that need to become structural. * web-sys: Test bindings for Event * ci: Use `--manifest-path dir` instead of `cd dir && ...` * web-sys: Just move .webidl files isntead of symlinking to enable them * tests: Polyfill Array.prototype.values for older browsers in CI * test-project-builder: Don't panic on poisoned headless test mutex We only use it to serialize headless tests so that we don't try to bind the port concurrently. Its OK to run another headless test if an earlier one panicked. * JsValue: Add {is,as}_{object,function} methods Allows dynamically casting values to `js::Object` and `js::Function`. * tidy: Fix whitespace and missing semicolons * Allow for dynamic feature detection of methods If we create bindings to a method that doesn't exist in this implementation, then it shouldn't fail until if/when we actually try and invoke that missing method. * tests: Do feature detection in Array.prototype.values test * Add JsValue::{is_string, as_js_string} methods And document all the cast/convert/check methods for js value. * eslint: allow backtick string literals * Only generate a fallback import function for non-structural imports
2018-07-09 16:35:25 -07:00
pub fn is_function(&self) -> bool {
unsafe { __wbindgen_is_function(self.idx) == 1 }
}
2019-01-10 23:37:12 +00:00
/// Get a string representation of the JavaScript object for debugging
#[cfg(feature = "std")]
2019-01-10 23:37:12 +00:00
fn as_debug_string(&self) -> String {
unsafe {
First refactor for WebIDL bindings This commit starts the `wasm-bindgen` CLI tool down the road to being a true polyfill for WebIDL bindings. This refactor is probably the first of a few, but is hopefully the largest and most sprawling and everything will be a bit more targeted from here on out. The goal of this refactoring is to separate out the massive `crates/cli-support/src/js/mod.rs` into a number of separate pieces of functionality. It currently takes care of basically everything including: * Binding intrinsics * Handling anyref transformations * Generating all JS for imports/exports * All the logic for how to import and how to name imports * Execution and management of wasm-bindgen closures Many of these are separable concerns and most overlap with WebIDL bindings. The internal refactoring here is intended to make it more clear who's responsible for what as well as making some existing operations much more straightforward. At a high-level, the following changes are done: 1. A `src/webidl.rs` module is introduced. The purpose of this module is to take all of the raw wasm-bindgen custom sections from the module and transform them into a WebIDL bindings section. This module has a placeholder `WebidlCustomSection` which is nowhere near the actual custom section but if you squint is in theory very similar. It's hoped that this will eventually become the true WebIDL custom section, currently being developed in an external crate. Currently, however, the WebIDL bindings custom section only covers a subset of the functionality we export to wasm-bindgen users. To avoid leaving them high and dry this module also contains an auxiliary custom section named `WasmBindgenAux`. This custom section isn't intended to have a binary format, but is intended to represent a theoretical custom section necessary to couple with WebIDL bindings to achieve all our desired functionality in `wasm-bindgen`. It'll never be standardized, but it'll also never be serialized :) 2. The `src/webidl.rs` module now takes over quite a bit of functionality from `src/js/mod.rs`. Namely it handles synthesis of an `export_map` and an `import_map` mapping export/import IDs to exactly what's expected to be hooked up there. This does not include type information (as that's in the bindings section) but rather includes things like "this is the method of class A" or "this import is from module `foo`" and things like that. These could arguably be subsumed by future JS features as well, but that's for another time! 3. All handling of wasm-bindgen "descriptor functions" now happens in a dedicated `src/descriptors.rs` module. The output of this module is its own custom section (intended to be immediately consumed by the WebIDL module) which is in theory what we want to ourselves emit one day but rustc isn't capable of doing so right now. 4. Invocations and generations of imports are completely overhauled. Using the `import_map` generated in the WebIDL step all imports are now handled much more precisely in one location rather than haphazardly throughout the module. This means we have precise information about each import of the module and we only modify exactly what we're looking at. This also vastly simplifies intrinsic generation since it's all simply a codegen part of the `rust2js.rs` module now. 5. Handling of direct imports which don't have a JS shim generated is slightly different from before and is intended to be future-compatible with WebIDL bindings in its full glory, but we'll need to update it to handle cases for constructors and method calls eventually as well. 6. Intrinsic definitions now live in their own file (`src/intrinsic.rs`) and have a separated definition for their symbol name and signature. The actual implementation of each intrinsic lives in `rust2js.rs` There's a number of TODO items to finish before this merges. This includes reimplementing the anyref pass and actually implementing import maps for other targets. Those will come soon in follow-up commits, but the entire `tests/wasm/main.rs` suite is currently passing and this seems like a good checkpoint.
2019-05-23 09:15:26 -07:00
let mut ret = [0; 2];
__wbindgen_debug_string(&mut ret, self.idx);
let data = Vec::from_raw_parts(ret[0] as *mut u8, ret[1], ret[1]);
String::from_utf8_unchecked(data)
}
}
}
impl PartialEq for JsValue {
#[inline]
fn eq(&self, other: &JsValue) -> bool {
2018-06-27 22:42:34 -07:00
unsafe { __wbindgen_jsval_eq(self.idx, other.idx) != 0 }
}
}
impl PartialEq<bool> for JsValue {
#[inline]
fn eq(&self, other: &bool) -> bool {
self.as_bool() == Some(*other)
}
}
impl PartialEq<str> for JsValue {
#[inline]
fn eq(&self, other: &str) -> bool {
*self == JsValue::from_str(other)
}
}
impl<'a> PartialEq<&'a str> for JsValue {
#[inline]
fn eq(&self, other: &&'a str) -> bool {
<JsValue as PartialEq<str>>::eq(self, other)
}
}
if_std! {
impl PartialEq<String> for JsValue {
#[inline]
fn eq(&self, other: &String) -> bool {
<JsValue as PartialEq<str>>::eq(self, other)
}
}
impl<'a> PartialEq<&'a String> for JsValue {
#[inline]
fn eq(&self, other: &&'a String) -> bool {
<JsValue as PartialEq<str>>::eq(self, other)
}
}
}
impl<'a> From<&'a str> for JsValue {
2018-11-27 12:07:59 -08:00
#[inline]
fn from(s: &'a str) -> JsValue {
JsValue::from_str(s)
}
}
if_std! {
impl<'a> From<&'a String> for JsValue {
#[inline]
fn from(s: &'a String) -> JsValue {
JsValue::from_str(s)
}
}
impl From<String> for JsValue {
#[inline]
fn from(s: String) -> JsValue {
JsValue::from_str(&s)
}
}
}
impl From<bool> for JsValue {
#[inline]
fn from(s: bool) -> JsValue {
JsValue::from_bool(s)
}
}
impl<'a, T> From<&'a T> for JsValue
where
T: JsCast,
{
#[inline]
fn from(s: &'a T) -> JsValue {
s.as_ref().clone()
}
}
impl<T> From<Option<T>> for JsValue
where
JsValue: From<T>,
{
#[inline]
fn from(s: Option<T>) -> JsValue {
match s {
Some(s) => s.into(),
None => JsValue::undefined(),
}
}
}
impl JsCast for JsValue {
// everything is a `JsValue`!
#[inline]
fn instanceof(_val: &JsValue) -> bool {
true
}
#[inline]
fn unchecked_from_js(val: JsValue) -> Self {
val
}
#[inline]
fn unchecked_from_js_ref(val: &JsValue) -> &Self {
val
}
}
impl AsRef<JsValue> for JsValue {
#[inline]
fn as_ref(&self) -> &JsValue {
self
}
}
macro_rules! numbers {
($($n:ident)*) => ($(
impl PartialEq<$n> for JsValue {
#[inline]
fn eq(&self, other: &$n) -> bool {
self.as_f64() == Some(f64::from(*other))
}
}
impl From<$n> for JsValue {
#[inline]
fn from(n: $n) -> JsValue {
JsValue::from_f64(n.into())
}
}
)*)
}
numbers! { i8 u8 i16 u16 i32 u32 f32 f64 }
externs! {
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
#[link(wasm_import_module = "__wbindgen_placeholder__")]
extern "C" {
fn __wbindgen_object_clone_ref(idx: u32) -> u32;
fn __wbindgen_object_drop_ref(idx: u32) -> ();
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
fn __wbindgen_string_new(ptr: *const u8, len: usize) -> u32;
fn __wbindgen_number_new(f: f64) -> u32;
fn __wbindgen_symbol_named_new(ptr: *const u8, len: usize) -> u32;
fn __wbindgen_symbol_anonymous_new() -> u32;
fn __wbindgen_anyref_heap_live_count() -> u32;
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
fn __wbindgen_is_null(idx: u32) -> u32;
fn __wbindgen_is_undefined(idx: u32) -> u32;
fn __wbindgen_is_symbol(idx: u32) -> u32;
fn __wbindgen_is_object(idx: u32) -> u32;
fn __wbindgen_is_function(idx: u32) -> u32;
fn __wbindgen_is_string(idx: u32) -> u32;
fn __wbindgen_number_get(idx: u32, invalid: *mut u8) -> f64;
fn __wbindgen_boolean_get(idx: u32) -> u32;
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
fn __wbindgen_string_get(idx: u32, len: *mut usize) -> *mut u8;
First refactor for WebIDL bindings This commit starts the `wasm-bindgen` CLI tool down the road to being a true polyfill for WebIDL bindings. This refactor is probably the first of a few, but is hopefully the largest and most sprawling and everything will be a bit more targeted from here on out. The goal of this refactoring is to separate out the massive `crates/cli-support/src/js/mod.rs` into a number of separate pieces of functionality. It currently takes care of basically everything including: * Binding intrinsics * Handling anyref transformations * Generating all JS for imports/exports * All the logic for how to import and how to name imports * Execution and management of wasm-bindgen closures Many of these are separable concerns and most overlap with WebIDL bindings. The internal refactoring here is intended to make it more clear who's responsible for what as well as making some existing operations much more straightforward. At a high-level, the following changes are done: 1. A `src/webidl.rs` module is introduced. The purpose of this module is to take all of the raw wasm-bindgen custom sections from the module and transform them into a WebIDL bindings section. This module has a placeholder `WebidlCustomSection` which is nowhere near the actual custom section but if you squint is in theory very similar. It's hoped that this will eventually become the true WebIDL custom section, currently being developed in an external crate. Currently, however, the WebIDL bindings custom section only covers a subset of the functionality we export to wasm-bindgen users. To avoid leaving them high and dry this module also contains an auxiliary custom section named `WasmBindgenAux`. This custom section isn't intended to have a binary format, but is intended to represent a theoretical custom section necessary to couple with WebIDL bindings to achieve all our desired functionality in `wasm-bindgen`. It'll never be standardized, but it'll also never be serialized :) 2. The `src/webidl.rs` module now takes over quite a bit of functionality from `src/js/mod.rs`. Namely it handles synthesis of an `export_map` and an `import_map` mapping export/import IDs to exactly what's expected to be hooked up there. This does not include type information (as that's in the bindings section) but rather includes things like "this is the method of class A" or "this import is from module `foo`" and things like that. These could arguably be subsumed by future JS features as well, but that's for another time! 3. All handling of wasm-bindgen "descriptor functions" now happens in a dedicated `src/descriptors.rs` module. The output of this module is its own custom section (intended to be immediately consumed by the WebIDL module) which is in theory what we want to ourselves emit one day but rustc isn't capable of doing so right now. 4. Invocations and generations of imports are completely overhauled. Using the `import_map` generated in the WebIDL step all imports are now handled much more precisely in one location rather than haphazardly throughout the module. This means we have precise information about each import of the module and we only modify exactly what we're looking at. This also vastly simplifies intrinsic generation since it's all simply a codegen part of the `rust2js.rs` module now. 5. Handling of direct imports which don't have a JS shim generated is slightly different from before and is intended to be future-compatible with WebIDL bindings in its full glory, but we'll need to update it to handle cases for constructors and method calls eventually as well. 6. Intrinsic definitions now live in their own file (`src/intrinsic.rs`) and have a separated definition for their symbol name and signature. The actual implementation of each intrinsic lives in `rust2js.rs` There's a number of TODO items to finish before this merges. This includes reimplementing the anyref pass and actually implementing import maps for other targets. Those will come soon in follow-up commits, but the entire `tests/wasm/main.rs` suite is currently passing and this seems like a good checkpoint.
2019-05-23 09:15:26 -07:00
fn __wbindgen_debug_string(ret: *mut [usize; 2], idx: u32) -> ();
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
fn __wbindgen_throw(a: *const u8, b: usize) -> !;
fn __wbindgen_rethrow(a: u32) -> !;
fn __wbindgen_cb_drop(idx: u32) -> u32;
fn __wbindgen_cb_forget(idx: u32) -> ();
fn __wbindgen_describe(v: u32) -> ();
fn __wbindgen_describe_closure(a: u32, b: u32, c: u32) -> u32;
fn __wbindgen_json_parse(ptr: *const u8, len: usize) -> u32;
First refactor for WebIDL bindings This commit starts the `wasm-bindgen` CLI tool down the road to being a true polyfill for WebIDL bindings. This refactor is probably the first of a few, but is hopefully the largest and most sprawling and everything will be a bit more targeted from here on out. The goal of this refactoring is to separate out the massive `crates/cli-support/src/js/mod.rs` into a number of separate pieces of functionality. It currently takes care of basically everything including: * Binding intrinsics * Handling anyref transformations * Generating all JS for imports/exports * All the logic for how to import and how to name imports * Execution and management of wasm-bindgen closures Many of these are separable concerns and most overlap with WebIDL bindings. The internal refactoring here is intended to make it more clear who's responsible for what as well as making some existing operations much more straightforward. At a high-level, the following changes are done: 1. A `src/webidl.rs` module is introduced. The purpose of this module is to take all of the raw wasm-bindgen custom sections from the module and transform them into a WebIDL bindings section. This module has a placeholder `WebidlCustomSection` which is nowhere near the actual custom section but if you squint is in theory very similar. It's hoped that this will eventually become the true WebIDL custom section, currently being developed in an external crate. Currently, however, the WebIDL bindings custom section only covers a subset of the functionality we export to wasm-bindgen users. To avoid leaving them high and dry this module also contains an auxiliary custom section named `WasmBindgenAux`. This custom section isn't intended to have a binary format, but is intended to represent a theoretical custom section necessary to couple with WebIDL bindings to achieve all our desired functionality in `wasm-bindgen`. It'll never be standardized, but it'll also never be serialized :) 2. The `src/webidl.rs` module now takes over quite a bit of functionality from `src/js/mod.rs`. Namely it handles synthesis of an `export_map` and an `import_map` mapping export/import IDs to exactly what's expected to be hooked up there. This does not include type information (as that's in the bindings section) but rather includes things like "this is the method of class A" or "this import is from module `foo`" and things like that. These could arguably be subsumed by future JS features as well, but that's for another time! 3. All handling of wasm-bindgen "descriptor functions" now happens in a dedicated `src/descriptors.rs` module. The output of this module is its own custom section (intended to be immediately consumed by the WebIDL module) which is in theory what we want to ourselves emit one day but rustc isn't capable of doing so right now. 4. Invocations and generations of imports are completely overhauled. Using the `import_map` generated in the WebIDL step all imports are now handled much more precisely in one location rather than haphazardly throughout the module. This means we have precise information about each import of the module and we only modify exactly what we're looking at. This also vastly simplifies intrinsic generation since it's all simply a codegen part of the `rust2js.rs` module now. 5. Handling of direct imports which don't have a JS shim generated is slightly different from before and is intended to be future-compatible with WebIDL bindings in its full glory, but we'll need to update it to handle cases for constructors and method calls eventually as well. 6. Intrinsic definitions now live in their own file (`src/intrinsic.rs`) and have a separated definition for their symbol name and signature. The actual implementation of each intrinsic lives in `rust2js.rs` There's a number of TODO items to finish before this merges. This includes reimplementing the anyref pass and actually implementing import maps for other targets. Those will come soon in follow-up commits, but the entire `tests/wasm/main.rs` suite is currently passing and this seems like a good checkpoint.
2019-05-23 09:15:26 -07:00
fn __wbindgen_json_serialize(ret: *mut [usize; 2], idx: u32) -> ();
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
fn __wbindgen_jsval_eq(a: u32, b: u32) -> u32;
fn __wbindgen_memory() -> u32;
fn __wbindgen_module() -> u32;
fn __wbindgen_function_table() -> u32;
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
}
}
impl Clone for JsValue {
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
#[inline]
fn clone(&self) -> JsValue {
unsafe {
2017-12-19 20:00:25 -08:00
let idx = __wbindgen_object_clone_ref(self.idx);
JsValue::_new(idx)
}
}
}
2019-01-10 23:37:12 +00:00
#[cfg(feature = "std")]
2018-07-05 20:14:38 -07:00
impl fmt::Debug for JsValue {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
2019-01-10 23:39:36 +00:00
write!(f, "JsValue({})", self.as_debug_string())
2019-01-10 23:37:12 +00:00
}
}
#[cfg(not(feature = "std"))]
impl fmt::Debug for JsValue {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
2019-01-11 19:24:24 +00:00
f.write_str("JsValue")
2018-07-05 20:14:38 -07:00
}
}
impl Drop for JsValue {
#[inline]
fn drop(&mut self) {
unsafe {
// We definitely should never drop anything in the stack area
debug_assert!(self.idx >= JSIDX_OFFSET, "free of stack slot {}", self.idx);
// Otherwise if we're not dropping one of our reserved values,
// actually call the intrinsic. See #1054 for eventually removing
// this branch.
if self.idx >= JSIDX_RESERVED {
__wbindgen_object_drop_ref(self.idx);
}
}
}
}
/// Wrapper type for imported statics.
///
/// This type is used whenever a `static` is imported from a JS module, for
/// example this import:
///
/// ```ignore
/// #[wasm_bindgen]
/// extern "C" {
/// static console: JsValue;
/// }
/// ```
///
/// will generate in Rust a value that looks like:
///
/// ```ignore
/// static console: JsStatic<JsValue> = ...;
/// ```
///
/// This type implements `Deref` to the inner type so it's typically used as if
/// it were `&T`.
#[cfg(feature = "std")]
pub struct JsStatic<T: 'static> {
#[doc(hidden)]
pub __inner: &'static std::thread::LocalKey<T>,
}
#[cfg(feature = "std")]
impl<T: FromWasmAbi + 'static> Deref for JsStatic<T> {
type Target = T;
fn deref(&self) -> &T {
// We know that our tls key is never overwritten after initialization,
// so it should be safe (on that axis at least) to hand out a reference
// that lives longer than the closure below.
//
// FIXME: this is not sound if we ever implement thread exit hooks on
// wasm, as the pointer will eventually be invalidated but you can get
// `&'static T` from this interface. We... probably need to deprecate
// and/or remove this interface nowadays.
2018-11-27 12:07:59 -08:00
unsafe { self.__inner.with(|ptr| &*(ptr as *const T)) }
}
}
#[cold]
#[inline(never)]
#[deprecated(note = "renamed to `throw_str`")]
#[doc(hidden)]
pub fn throw(s: &str) -> ! {
throw_str(s)
}
/// Throws a JS exception.
///
/// This function will throw a JS exception with the message provided. The
/// function will not return as the wasm stack will be popped when the exception
/// is thrown.
///
/// Note that it is very easy to leak memory with this function because this
/// function, unlike `panic!` on other platforms, **will not run destructors**.
/// It's recommended to return a `Result` where possible to avoid the worry of
/// leaks.
#[cold]
#[inline(never)]
pub fn throw_str(s: &str) -> ! {
unsafe {
__wbindgen_throw(s.as_ptr(), s.len());
}
}
/// Rethrow a JS exception
///
/// This function will throw a JS exception with the JS value provided. This
/// function will not return and the wasm stack will be popped until the point
/// of entry of wasm itself.
///
/// Note that it is very easy to leak memory with this function because this
/// function, unlike `panic!` on other platforms, **will not run destructors**.
/// It's recommended to return a `Result` where possible to avoid the worry of
/// leaks.
#[cold]
#[inline(never)]
pub fn throw_val(s: JsValue) -> ! {
unsafe {
let idx = s.idx;
mem::forget(s);
__wbindgen_rethrow(idx);
}
}
/// Get the count of live `anyref`s / `JsValue`s in `wasm-bindgen`'s heap.
///
/// ## Usage
///
/// This is intended for debugging and writing tests.
///
/// To write a test that asserts against unnecessarily keeping `anref`s /
/// `JsValue`s alive:
///
/// * get an initial live count,
///
/// * perform some series of operations or function calls that should clean up
/// after themselves, and should not keep holding onto `anyref`s / `JsValue`s
/// after completion,
///
/// * get the final live count,
///
/// * and assert that the initial and final counts are the same.
///
/// ## What is Counted
///
/// Note that this only counts the *owned* `anyref`s / `JsValue`s that end up in
/// `wasm-bindgen`'s heap. It does not count borrowed `anyref`s / `JsValue`s
/// that are on its stack.
///
/// For example, these `JsValue`s are accounted for:
///
/// ```ignore
/// #[wasm_bindgen]
/// pub fn my_function(this_is_counted: JsValue) {
/// let also_counted = JsValue::from_str("hi");
/// assert!(wasm_bindgen::anyref_heap_live_count() >= 2);
/// }
/// ```
///
/// While this borrowed `JsValue` ends up on the stack, not the heap, and
/// therefore is not accounted for:
///
/// ```ignore
/// #[wasm_bindgen]
/// pub fn my_other_function(this_is_not_counted: &JsValue) {
/// // ...
/// }
/// ```
pub fn anyref_heap_live_count() -> u32 {
2019-05-28 09:52:44 -05:00
unsafe { __wbindgen_anyref_heap_live_count() }
}
/// An extension trait for `Option<T>` and `Result<T, E>` for unwraping the `T`
/// value, or throwing a JS error if it is not available.
///
/// These methods should have a smaller code size footprint than the normal
/// `Option::unwrap` and `Option::expect` methods, but they are specific to
/// working with wasm and JS.
///
/// On non-wasm32 targets, defaults to the normal unwrap/expect calls.
///
/// # Example
///
2019-02-20 10:48:01 -08:00
/// ```
/// use wasm_bindgen::prelude::*;
///
/// // If the value is `Option::Some` or `Result::Ok`, then we just get the
/// // contained `T` value.
/// let x = Some(42);
/// assert_eq!(x.unwrap_throw(), 42);
///
/// let y: Option<i32> = None;
///
/// // This call would throw an error to JS!
/// //
/// // y.unwrap_throw()
/// //
/// // And this call would throw an error to JS with a custom error message!
/// //
/// // y.expect_throw("woopsie daisy!")
/// ```
pub trait UnwrapThrowExt<T>: Sized {
/// Unwrap this `Option` or `Result`, but instead of panicking on failure,
/// throw an exception to JavaScript.
fn unwrap_throw(self) -> T {
self.expect_throw("`unwrap_throw` failed")
}
/// Unwrap this container's `T` value, or throw an error to JS with the
/// given message if the `T` value is unavailable (e.g. an `Option<T>` is
/// `None`).
fn expect_throw(self, message: &str) -> T;
}
impl<T> UnwrapThrowExt<T> for Option<T> {
fn expect_throw(self, message: &str) -> T {
if cfg!(all(target_arch = "wasm32", not(target_os = "emscripten"))) {
match self {
Some(val) => val,
None => throw_str(message),
}
} else {
self.expect(message)
}
}
}
impl<T, E> UnwrapThrowExt<T> for Result<T, E>
where
E: core::fmt::Debug,
{
fn expect_throw(self, message: &str) -> T {
if cfg!(all(target_arch = "wasm32", not(target_os = "emscripten"))) {
match self {
Ok(val) => val,
Err(_) => throw_str(message),
}
} else {
self.expect(message)
}
}
}
/// Returns a handle to this wasm instance's `WebAssembly.Module`
///
/// Note that this is only available when the final wasm app is built with
/// `--target no-modules`, it's not recommended to rely on this API yet! This is
/// largely just an experimental addition to enable threading demos. Using this
/// may prevent your wasm module from building down the road.
#[doc(hidden)]
pub fn module() -> JsValue {
2018-11-27 12:07:59 -08:00
unsafe { JsValue::_new(__wbindgen_module()) }
}
/// Returns a handle to this wasm instance's `WebAssembly.Memory`
pub fn memory() -> JsValue {
2018-11-27 12:07:59 -08:00
unsafe { JsValue::_new(__wbindgen_memory()) }
}
/// Returns a handle to this wasm instance's `WebAssembly.Table` which is the
/// indirect function table used by Rust
pub fn function_table() -> JsValue {
unsafe { JsValue::_new(__wbindgen_function_table()) }
}
#[doc(hidden)]
pub mod __rt {
use core::cell::{Cell, UnsafeCell};
use core::ops::{Deref, DerefMut};
pub extern crate core;
#[cfg(feature = "std")]
pub extern crate std;
#[macro_export]
#[doc(hidden)]
#[cfg(feature = "std")]
macro_rules! __wbindgen_if_not_std {
2018-06-27 22:42:34 -07:00
($($i:item)*) => {};
}
#[macro_export]
#[doc(hidden)]
#[cfg(not(feature = "std"))]
macro_rules! __wbindgen_if_not_std {
($($i:item)*) => ($($i)*)
}
#[inline]
pub fn assert_not_null<T>(s: *mut T) {
if s.is_null() {
throw_null();
}
}
#[cold]
#[inline(never)]
fn throw_null() -> ! {
super::throw_str("null pointer passed to rust");
}
/// A vendored version of `RefCell` from the standard library.
///
/// Now why, you may ask, would we do that? Surely `RefCell` in libstd is
/// quite good. And you're right, it is indeed quite good! Functionally
/// nothing more is needed from `RefCell` in the standard library but for
/// now this crate is also sort of optimizing for compiled code size.
///
/// One major factor to larger binaries in Rust is when a panic happens.
/// Panicking in the standard library involves a fair bit of machinery
/// (formatting, panic hooks, synchronization, etc). It's all worthwhile if
/// you need it but for something like `WasmRefCell` here we don't actually
/// need all that!
///
/// This is just a wrapper around all Rust objects passed to JS intended to
/// guard accidental reentrancy, so this vendored version is intended solely
/// to not panic in libstd. Instead when it "panics" it calls our `throw`
/// function in this crate which raises an error in JS.
pub struct WasmRefCell<T: ?Sized> {
borrow: Cell<usize>,
value: UnsafeCell<T>,
}
impl<T: ?Sized> WasmRefCell<T> {
2018-06-27 22:42:34 -07:00
pub fn new(value: T) -> WasmRefCell<T>
where
T: Sized,
{
WasmRefCell {
value: UnsafeCell::new(value),
borrow: Cell::new(0),
}
}
2017-12-21 12:28:30 -08:00
pub fn get_mut(&mut self) -> &mut T {
2018-06-27 22:42:34 -07:00
unsafe { &mut *self.value.get() }
2017-12-21 12:28:30 -08:00
}
pub fn borrow(&self) -> Ref<T> {
unsafe {
if self.borrow.get() == usize::max_value() {
borrow_fail();
}
self.borrow.set(self.borrow.get() + 1);
Ref {
value: &*self.value.get(),
borrow: &self.borrow,
}
}
}
pub fn borrow_mut(&self) -> RefMut<T> {
unsafe {
if self.borrow.get() != 0 {
borrow_fail();
}
self.borrow.set(usize::max_value());
RefMut {
value: &mut *self.value.get(),
borrow: &self.borrow,
}
}
}
2018-06-27 22:42:34 -07:00
pub fn into_inner(self) -> T
where
T: Sized,
{
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
self.value.into_inner()
}
}
pub struct Ref<'b, T: ?Sized + 'b> {
value: &'b T,
borrow: &'b Cell<usize>,
}
impl<'b, T: ?Sized> Deref for Ref<'b, T> {
type Target = T;
#[inline]
fn deref(&self) -> &T {
self.value
}
}
impl<'b, T: ?Sized> Drop for Ref<'b, T> {
fn drop(&mut self) {
self.borrow.set(self.borrow.get() - 1);
}
}
pub struct RefMut<'b, T: ?Sized + 'b> {
value: &'b mut T,
borrow: &'b Cell<usize>,
}
impl<'b, T: ?Sized> Deref for RefMut<'b, T> {
type Target = T;
#[inline]
fn deref(&self) -> &T {
self.value
}
}
impl<'b, T: ?Sized> DerefMut for RefMut<'b, T> {
#[inline]
fn deref_mut(&mut self) -> &mut T {
self.value
}
}
impl<'b, T: ?Sized> Drop for RefMut<'b, T> {
fn drop(&mut self) {
self.borrow.set(0);
}
}
fn borrow_fail() -> ! {
super::throw_str(
2018-06-27 22:42:34 -07:00
"recursive use of an object detected which would lead to \
unsafe aliasing in rust",
);
}
if_std! {
use std::alloc::{alloc, dealloc, realloc, Layout};
use std::mem;
#[no_mangle]
pub extern "C" fn __wbindgen_malloc(size: usize) -> *mut u8 {
let align = mem::align_of::<usize>();
if let Ok(layout) = Layout::from_size_align(size, align) {
unsafe {
if layout.size() > 0 {
let ptr = alloc(layout);
if !ptr.is_null() {
return ptr
}
} else {
return align as *mut u8
}
}
}
malloc_failure();
}
#[no_mangle]
2019-05-28 09:52:44 -05:00
pub unsafe extern "C" fn __wbindgen_realloc(ptr: *mut u8, old_size: usize, new_size: usize) -> *mut u8 {
let align = mem::align_of::<usize>();
debug_assert!(old_size > 0);
debug_assert!(new_size > 0);
if let Ok(layout) = Layout::from_size_align(old_size, align) {
2019-05-28 09:52:44 -05:00
let ptr = realloc(ptr, layout, new_size);
if !ptr.is_null() {
return ptr
}
}
malloc_failure();
}
#[cold]
fn malloc_failure() -> ! {
if cfg!(debug_assertions) {
super::throw_str("invalid malloc request")
} else {
std::process::abort();
}
}
#[no_mangle]
pub unsafe extern "C" fn __wbindgen_free(ptr: *mut u8, size: usize) {
Add support for optional slice types (#507) * Shard the `convert.rs` module into sub-modules Hopefully this'll make the organization a little nicer over time! * Start adding support for optional types This commit starts adding support for optional types to wasm-bindgen as arguments/return values to functions. The strategy here is to add two new traits, `OptionIntoWasmAbi` and `OptionFromWasmAbi`. These two traits are used as a blanket impl to implement `IntoWasmAbi` and `FromWasmAbi` for `Option<T>`. Some consequences of this design: * It should be possible to ensure `Option<SomeForeignType>` implements to/from wasm traits. This is because the option-based traits can be implemented for foreign types. * A specialized implementation is possible for all types, so there's no need for `Option<T>` to introduce unnecessary overhead. * Two new traits is a bit unforutnate but I can't currently think of an alternative design that works for the above two constraints, although it doesn't mean one doesn't exist! * The error messages for "can't use this type here" is actually halfway decent because it says these new traits need to be implemented, which provides a good place to document and talk about what's going on here! * Nested references like `Option<&T>` can't implement `FromWasmAbi`. This means that you can't define a function in Rust which takes `Option<&str>`. It may be possible to do this one day but it'll likely require more trait trickery than I'm capable of right now. * Add support for optional slices This commit adds support for optional slice types, things like strings and arrays. The null representation of these has a pointer value of 0, which should never happen in normal Rust. Otherwise the various plumbing is done throughout the tooling to enable these types in all locations. * Fix `takeObject` on global sentinels These don't have a reference count as they're always expected to work, so avoid actually dropping a reference on them. * Remove some no longer needed bindings * Add support for optional anyref types This commit adds support for optional imported class types. Each type imported with `#[wasm_bindgen]` automatically implements the relevant traits and now supports `Option<Foo>` in various argument/return positions. * Fix building without the `std` feature * Actually fix the build... * Add support for optional types to WebIDL Closes #502
2018-07-19 14:44:23 -05:00
// This happens for zero-length slices, and in that case `ptr` is
// likely bogus so don't actually send this to the system allocator
if size == 0 {
return
}
let align = mem::align_of::<usize>();
let layout = Layout::from_size_align_unchecked(size, align);
dealloc(ptr, layout);
}
}
pub const GLOBAL_STACK_CAP: usize = 16;
// Increase the alignment to 8 here because this can be used as a
// BigUint64Array pointer base which requires alignment 8
#[repr(align(8))]
struct GlobalData([u32; GLOBAL_STACK_CAP]);
static mut GLOBAL_STACK: GlobalData = GlobalData([0; GLOBAL_STACK_CAP]);
#[no_mangle]
pub unsafe extern "C" fn __wbindgen_global_argument_ptr() -> *mut u32 {
GLOBAL_STACK.0.as_mut_ptr()
}
/// This is a curious function necessary to get wasm-bindgen working today,
/// and it's a bit of an unfortunate hack.
///
/// The general problem is that somehow we need the above two symbols to
/// exist in the final output binary (__wbindgen_malloc and
/// __wbindgen_free). These symbols may be called by JS for various
/// bindings, so we for sure need to make sure they're exported.
///
/// The problem arises, though, when what if no Rust code uses the symbols?
/// For all intents and purposes it looks to LLVM and the linker like the
/// above two symbols are dead code, so they're completely discarded!
///
/// Specifically what happens is this:
///
/// * The above two symbols are generated into some object file inside of
/// libwasm_bindgen.rlib
/// * The linker, LLD, will not load this object file unless *some* symbol
/// is loaded from the object. In this case, if the Rust code never calls
/// __wbindgen_malloc or __wbindgen_free then the symbols never get linked
/// in.
/// * Later when `wasm-bindgen` attempts to use the symbols they don't
/// exist, causing an error.
///
/// This function is a weird hack for this problem. We inject a call to this
/// function in all generated code. Usage of this function should then
/// ensure that the above two intrinsics are translated.
///
/// Due to how rustc creates object files this function (and anything inside
/// it) will be placed into the same object file as the two intrinsics
/// above. That means if this function is called and referenced we'll pull
/// in the object file and link the intrinsics.
///
/// Ideas for how to improve this are most welcome!
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
pub fn link_mem_intrinsics() {
crate::anyref::link_intrinsics();
Add experimental support for the `anyref` type 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.
2018-10-18 08:43:36 -07:00
}
static mut GLOBAL_EXNDATA: [u32; 2] = [0; 2];
#[no_mangle]
pub unsafe extern "C" fn __wbindgen_exn_store(idx: u32) {
assert_eq!(GLOBAL_EXNDATA[0], 0);
GLOBAL_EXNDATA[0] = 1;
GLOBAL_EXNDATA[1] = idx;
}
pub fn take_last_exception() -> Result<(), super::JsValue> {
unsafe {
let ret = if GLOBAL_EXNDATA[0] == 1 {
2019-06-13 08:30:06 -07:00
Err(super::JsValue::_new(GLOBAL_EXNDATA[1]))
} else {
Ok(())
};
GLOBAL_EXNDATA[0] = 0;
GLOBAL_EXNDATA[1] = 0;
return ret;
}
}
}
/// A wrapper type around slices and vectors for binding the `Uint8ClampedArray`
/// array in JS.
///
/// If you need to invoke a JS API which must take `Uint8ClampedArray` array,
/// then you can define it as taking one of these types:
///
/// * `Clamped<&[u8]>`
/// * `Clamped<&mut [u8]>`
/// * `Clamped<Vec<u8>>`
///
/// All of these types will show up as `Uint8ClampedArray` in JS and will have
/// different forms of ownership in Rust.
#[derive(Copy, Clone, PartialEq, Debug, Eq)]
pub struct Clamped<T>(pub T);
impl<T> Deref for Clamped<T> {
type Target = T;
fn deref(&self) -> &T {
&self.0
}
}
impl<T> DerefMut for Clamped<T> {
fn deref_mut(&mut self) -> &mut T {
&mut self.0
}
}