2018-07-07 10:20:31 -07:00
|
|
|
use proc_macro2::{Ident, Span};
|
2018-02-06 07:56:14 -08:00
|
|
|
use shared;
|
2017-12-14 19:31:01 -08:00
|
|
|
use syn;
|
|
|
|
|
2018-07-24 17:37:49 +01:00
|
|
|
/// An abstract syntax tree representing a rust program. Contains
|
|
|
|
/// extra information for joining up this rust code with javascript.
|
2018-07-17 16:28:44 +01:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq))]
|
2018-05-29 11:24:40 -07:00
|
|
|
#[derive(Default)]
|
2017-12-18 12:39:14 -08:00
|
|
|
pub struct Program {
|
2018-07-24 17:37:49 +01:00
|
|
|
/// rust -> js interfaces
|
2018-02-07 16:41:33 -08:00
|
|
|
pub exports: Vec<Export>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// js -> rust interfaces
|
2017-12-18 21:43:16 -08:00
|
|
|
pub imports: Vec<Import>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// rust enums
|
2018-02-22 00:55:11 +01:00
|
|
|
pub enums: Vec<Enum>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// rust structs
|
2018-02-07 16:41:33 -08:00
|
|
|
pub structs: Vec<Struct>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// rust type aliases
|
2018-06-11 18:35:20 -07:00
|
|
|
pub type_aliases: Vec<TypeAlias>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// rust consts
|
2018-07-13 22:36:51 -07:00
|
|
|
pub consts: Vec<Const>,
|
2017-12-18 12:39:14 -08:00
|
|
|
}
|
|
|
|
|
2018-07-24 17:37:49 +01:00
|
|
|
/// A rust to js interface. Allows interaction with rust objects/functions
|
|
|
|
/// from javascript.
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-02-07 16:41:33 -08:00
|
|
|
pub struct Export {
|
2018-07-24 17:37:49 +01:00
|
|
|
/// The javascript class name.
|
2018-05-21 07:29:34 -07:00
|
|
|
pub class: Option<Ident>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// The type of `self` (either `self`, `&self`, or `&mut self`)
|
2018-06-28 20:09:11 -05:00
|
|
|
pub method_self: Option<MethodSelf>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// The name of the constructor function (e.g. new).
|
|
|
|
///
|
|
|
|
/// This allows javascript to expose an `Object` interface, where calling
|
|
|
|
/// the constructor maps correctly to rust.
|
2018-04-14 16:41:41 +02:00
|
|
|
pub constructor: Option<String>,
|
2018-07-24 17:37:49 +01:00
|
|
|
/// The rust function
|
2018-02-07 16:41:33 -08:00
|
|
|
pub function: Function,
|
2018-07-25 18:08:57 +01:00
|
|
|
/// Comments extracted from the rust source.
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2018-07-25 18:08:57 +01:00
|
|
|
/// The name of the rust function/method on the rust side.
|
2018-07-20 12:01:28 -05:00
|
|
|
pub rust_name: Ident,
|
2017-12-14 19:31:01 -08:00
|
|
|
}
|
|
|
|
|
2018-07-25 18:08:57 +01:00
|
|
|
/// The 3 types variations of `self`.
|
2018-06-28 20:09:11 -05:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
|
|
|
pub enum MethodSelf {
|
2018-07-25 18:08:57 +01:00
|
|
|
/// `self`
|
2018-06-28 20:09:11 -05:00
|
|
|
ByValue,
|
2018-07-25 18:08:57 +01:00
|
|
|
/// `&mut self`
|
2018-06-28 20:09:11 -05:00
|
|
|
RefMutable,
|
2018-07-25 18:08:57 +01:00
|
|
|
/// `&self`
|
2018-06-28 20:09:11 -05:00
|
|
|
RefShared,
|
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2017-12-18 21:43:16 -08:00
|
|
|
pub struct Import {
|
2018-02-07 16:41:33 -08:00
|
|
|
pub module: Option<String>,
|
2018-04-25 07:26:33 -07:00
|
|
|
pub version: Option<String>,
|
2018-05-21 07:29:34 -07:00
|
|
|
pub js_namespace: Option<Ident>,
|
2018-02-07 16:41:33 -08:00
|
|
|
pub kind: ImportKind,
|
2018-02-05 14:24:25 -08:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-02-07 16:41:33 -08:00
|
|
|
pub enum ImportKind {
|
2018-03-21 09:55:16 -07:00
|
|
|
Function(ImportFunction),
|
|
|
|
Static(ImportStatic),
|
|
|
|
Type(ImportType),
|
2018-07-08 22:09:00 -04:00
|
|
|
Enum(ImportEnum),
|
2018-03-21 09:55:16 -07:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-03-21 09:55:16 -07:00
|
|
|
pub struct ImportFunction {
|
|
|
|
pub function: Function,
|
2018-05-21 07:29:34 -07:00
|
|
|
pub rust_name: Ident,
|
2018-06-14 02:03:52 -07:00
|
|
|
pub js_ret: Option<syn::Type>,
|
2018-07-07 10:20:31 -07:00
|
|
|
pub catch: bool,
|
|
|
|
pub structural: bool,
|
2018-03-21 09:55:16 -07:00
|
|
|
pub kind: ImportFunctionKind,
|
2018-05-21 07:29:34 -07:00
|
|
|
pub shim: Ident,
|
2018-03-21 09:55:16 -07:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-03-21 09:55:16 -07:00
|
|
|
pub enum ImportFunctionKind {
|
2018-06-14 19:21:33 -07:00
|
|
|
Method {
|
|
|
|
class: String,
|
|
|
|
ty: syn::Type,
|
|
|
|
kind: MethodKind,
|
|
|
|
},
|
2018-02-07 16:41:33 -08:00
|
|
|
Normal,
|
2018-02-05 14:24:25 -08:00
|
|
|
}
|
|
|
|
|
2018-06-14 19:21:33 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
|
|
|
pub enum MethodKind {
|
|
|
|
Constructor,
|
2018-07-07 10:20:31 -07:00
|
|
|
Operation(Operation),
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
|
|
|
pub struct Operation {
|
|
|
|
pub is_static: bool,
|
|
|
|
pub kind: OperationKind,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
|
|
|
pub enum OperationKind {
|
|
|
|
Regular,
|
|
|
|
Setter(Option<Ident>),
|
|
|
|
Getter(Option<Ident>),
|
2018-06-14 19:21:33 -07:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-03-21 09:55:16 -07:00
|
|
|
pub struct ImportStatic {
|
|
|
|
pub vis: syn::Visibility,
|
|
|
|
pub ty: syn::Type,
|
2018-05-21 07:29:34 -07:00
|
|
|
pub shim: Ident,
|
|
|
|
pub rust_name: Ident,
|
|
|
|
pub js_name: Ident,
|
2018-03-21 09:55:16 -07:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-03-21 09:55:16 -07:00
|
|
|
pub struct ImportType {
|
|
|
|
pub vis: syn::Visibility,
|
2018-05-21 07:29:34 -07:00
|
|
|
pub name: Ident,
|
2018-07-05 20:28:52 -07:00
|
|
|
pub attrs: Vec<syn::Attribute>,
|
2018-03-21 09:55:16 -07:00
|
|
|
}
|
|
|
|
|
2018-07-08 22:09:00 -04:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
|
|
|
pub struct ImportEnum {
|
|
|
|
/// The Rust enum's visibility
|
|
|
|
pub vis: syn::Visibility,
|
|
|
|
/// The Rust enum's identifiers
|
|
|
|
pub name: Ident,
|
|
|
|
/// The Rust identifiers for the variants
|
|
|
|
pub variants: Vec<Ident>,
|
|
|
|
/// The JS string values of the variants
|
|
|
|
pub variant_values: Vec<String>,
|
2018-07-23 11:04:28 -04:00
|
|
|
/// Attributes to apply to the Rust enum
|
|
|
|
pub rust_attrs: Vec<syn::Attribute>,
|
2018-07-08 22:09:00 -04:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-02-07 16:41:33 -08:00
|
|
|
pub struct Function {
|
2018-05-21 07:29:34 -07:00
|
|
|
pub name: Ident,
|
2018-06-14 02:03:52 -07:00
|
|
|
pub arguments: Vec<syn::ArgCaptured>,
|
2018-04-13 22:58:35 -07:00
|
|
|
pub ret: Option<syn::Type>,
|
2018-02-07 16:41:33 -08:00
|
|
|
pub rust_attrs: Vec<syn::Attribute>,
|
|
|
|
pub rust_vis: syn::Visibility,
|
2018-02-06 15:19:47 -08:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-02-07 16:41:33 -08:00
|
|
|
pub struct Struct {
|
2018-05-21 07:29:34 -07:00
|
|
|
pub name: Ident,
|
2018-04-19 16:49:46 -07:00
|
|
|
pub fields: Vec<StructField>,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-04-19 16:49:46 -07:00
|
|
|
pub struct StructField {
|
2018-05-21 07:29:34 -07:00
|
|
|
pub name: Ident,
|
|
|
|
pub struct_name: Ident,
|
2018-07-07 10:20:31 -07:00
|
|
|
pub readonly: bool,
|
2018-04-19 16:49:46 -07:00
|
|
|
pub ty: syn::Type,
|
2018-05-21 07:29:34 -07:00
|
|
|
pub getter: Ident,
|
|
|
|
pub setter: Ident,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2017-12-18 21:43:16 -08:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-02-22 00:55:11 +01:00
|
|
|
pub struct Enum {
|
2018-05-21 07:29:34 -07:00
|
|
|
pub name: Ident,
|
2018-03-29 09:14:32 -07:00
|
|
|
pub variants: Vec<Variant>,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2018-03-07 16:28:42 -08:00
|
|
|
}
|
|
|
|
|
2018-05-29 11:24:40 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
2018-03-07 16:28:42 -08:00
|
|
|
pub struct Variant {
|
2018-05-21 07:29:34 -07:00
|
|
|
pub name: Ident,
|
2018-03-07 16:28:42 -08:00
|
|
|
pub value: u32,
|
2018-02-22 00:55:11 +01:00
|
|
|
}
|
|
|
|
|
2018-05-25 16:31:48 -07:00
|
|
|
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
|
2018-04-04 08:24:19 -07:00
|
|
|
pub enum TypeKind {
|
|
|
|
ByRef,
|
|
|
|
ByMutRef,
|
|
|
|
ByValue,
|
|
|
|
}
|
|
|
|
|
2018-05-25 16:31:48 -07:00
|
|
|
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
|
2018-04-04 08:24:19 -07:00
|
|
|
pub enum TypeLocation {
|
|
|
|
ImportArgument,
|
|
|
|
ImportRet,
|
|
|
|
ExportArgument,
|
|
|
|
ExportRet,
|
2017-12-18 12:39:14 -08:00
|
|
|
}
|
|
|
|
|
2018-06-11 18:35:20 -07:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq, Eq))]
|
|
|
|
pub struct TypeAlias {
|
|
|
|
pub vis: syn::Visibility,
|
|
|
|
pub dest: Ident,
|
|
|
|
pub src: syn::Type,
|
|
|
|
}
|
|
|
|
|
2018-07-17 16:28:44 +01:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq))]
|
2018-07-13 04:16:19 +02:00
|
|
|
pub struct Const {
|
|
|
|
pub vis: syn::Visibility,
|
|
|
|
pub name: Ident,
|
2018-07-13 22:36:51 -07:00
|
|
|
pub class: Option<Ident>,
|
2018-07-13 04:16:19 +02:00
|
|
|
pub ty: syn::Type,
|
|
|
|
pub value: ConstValue,
|
|
|
|
}
|
|
|
|
|
2018-07-17 16:28:44 +01:00
|
|
|
#[cfg_attr(feature = "extra-traits", derive(Debug, PartialEq))]
|
2018-07-13 04:16:19 +02:00
|
|
|
/// same as webidl::ast::ConstValue
|
|
|
|
pub enum ConstValue {
|
|
|
|
BooleanLiteral(bool),
|
|
|
|
FloatLiteral(f64),
|
2018-07-14 14:48:04 +02:00
|
|
|
SignedIntegerLiteral(i64),
|
|
|
|
UnsignedIntegerLiteral(u64),
|
2018-07-13 04:16:19 +02:00
|
|
|
Null,
|
|
|
|
}
|
|
|
|
|
2017-12-18 12:39:14 -08:00
|
|
|
impl Program {
|
2018-07-07 10:20:31 -07:00
|
|
|
pub(crate) fn shared(&self) -> shared::Program {
|
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
|
|
|
shared::Program {
|
|
|
|
exports: self.exports.iter().map(|a| a.shared()).collect(),
|
2018-04-19 16:49:46 -07:00
|
|
|
structs: self.structs.iter().map(|a| a.shared()).collect(),
|
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
|
|
|
enums: self.enums.iter().map(|a| a.shared()).collect(),
|
|
|
|
imports: self.imports.iter().map(|a| a.shared()).collect(),
|
|
|
|
version: shared::version(),
|
|
|
|
schema_version: shared::SCHEMA_VERSION.to_string(),
|
|
|
|
}
|
2017-12-18 12:39:14 -08:00
|
|
|
}
|
2017-12-14 19:31:01 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Function {
|
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
|
|
|
fn shared(&self) -> shared::Function {
|
|
|
|
shared::Function {
|
2018-05-21 07:29:34 -07:00
|
|
|
name: self.name.to_string(),
|
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
|
|
|
}
|
|
|
|
}
|
2017-12-14 19:31:01 -08:00
|
|
|
}
|
|
|
|
|
2018-02-07 16:41:33 -08:00
|
|
|
impl Export {
|
2018-07-24 17:37:49 +01:00
|
|
|
/// Mangles a rust -> javascript export, so that the created Ident will be unique over function
|
|
|
|
/// name and class name, if the function belongs to a javascript class.
|
2018-07-07 10:20:31 -07:00
|
|
|
pub(crate) fn rust_symbol(&self) -> Ident {
|
2018-07-15 12:43:55 -04:00
|
|
|
let mut generated_name = String::from("__wasm_bindgen_generated");
|
2018-05-21 07:29:34 -07:00
|
|
|
if let Some(class) = &self.class {
|
2018-02-07 16:41:33 -08:00
|
|
|
generated_name.push_str("_");
|
2018-05-21 07:29:34 -07:00
|
|
|
generated_name.push_str(&class.to_string());
|
2017-12-18 12:39:14 -08:00
|
|
|
}
|
2018-02-07 16:41:33 -08:00
|
|
|
generated_name.push_str("_");
|
2018-05-21 07:29:34 -07:00
|
|
|
generated_name.push_str(&self.function.name.to_string());
|
|
|
|
Ident::new(&generated_name, Span::call_site())
|
2017-12-18 12:39:14 -08:00
|
|
|
}
|
|
|
|
|
2018-07-25 18:08:57 +01:00
|
|
|
/// This is the name of the shim function that gets exported and takes the raw
|
|
|
|
/// ABI form of its arguments and converts them back into their normal,
|
|
|
|
/// "high level" form before calling the actual function.
|
2018-07-07 10:20:31 -07:00
|
|
|
pub(crate) fn export_name(&self) -> String {
|
2018-05-21 07:29:34 -07:00
|
|
|
let fn_name = self.function.name.to_string();
|
|
|
|
match &self.class {
|
2018-05-31 22:51:40 -07:00
|
|
|
Some(class) => shared::struct_function_export_name(&class.to_string(), &fn_name),
|
2018-05-21 07:29:34 -07:00
|
|
|
None => shared::free_function_export_name(&fn_name),
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn shared(&self) -> shared::Export {
|
2018-06-28 20:09:11 -05:00
|
|
|
let (method, consumed) = match self.method_self {
|
|
|
|
Some(MethodSelf::ByValue) => (true, true),
|
|
|
|
Some(_) => (true, false),
|
|
|
|
None => (false, false),
|
|
|
|
};
|
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
|
|
|
shared::Export {
|
2018-05-21 07:29:34 -07:00
|
|
|
class: self.class.as_ref().map(|s| s.to_string()),
|
2018-06-28 20:09:11 -05:00
|
|
|
method,
|
|
|
|
consumed,
|
2018-04-14 16:41:41 +02:00
|
|
|
constructor: self.constructor.clone(),
|
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
|
|
|
function: self.function.shared(),
|
2018-06-15 11:20:56 -05:00
|
|
|
comments: self.comments.clone(),
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Enum {
|
|
|
|
fn shared(&self) -> shared::Enum {
|
|
|
|
shared::Enum {
|
2018-05-21 07:29:34 -07:00
|
|
|
name: self.name.to_string(),
|
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
|
|
|
variants: self.variants.iter().map(|v| v.shared()).collect(),
|
2018-06-15 11:20:56 -05:00
|
|
|
comments: self.comments.clone(),
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Variant {
|
|
|
|
fn shared(&self) -> shared::EnumVariant {
|
|
|
|
shared::EnumVariant {
|
2018-05-21 07:29:34 -07:00
|
|
|
name: self.name.to_string(),
|
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
|
|
|
value: self.value,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Import {
|
|
|
|
fn shared(&self) -> shared::Import {
|
2018-04-25 07:26:33 -07:00
|
|
|
match (&self.module, &self.version) {
|
|
|
|
(&Some(ref m), None) if m.starts_with("./") => {}
|
|
|
|
(&Some(ref m), &Some(_)) if m.starts_with("./") => {
|
2018-05-31 22:51:40 -07:00
|
|
|
panic!(
|
|
|
|
"when a module path starts with `./` that indicates \
|
|
|
|
that a local file is being imported so the `version` \
|
|
|
|
key cannot also be specified"
|
|
|
|
);
|
2018-04-25 07:26:33 -07:00
|
|
|
}
|
|
|
|
(&Some(_), &Some(_)) => {}
|
2018-05-31 22:51:40 -07:00
|
|
|
(&Some(_), &None) => panic!(
|
|
|
|
"when the `module` directive doesn't start with `./` \
|
|
|
|
then it's interpreted as an NPM package which requires \
|
|
|
|
a `version` to be specified as well, try using \
|
|
|
|
#[wasm_bindgen(module = \"...\", version = \"...\")]"
|
|
|
|
),
|
2018-04-25 07:26:33 -07:00
|
|
|
(&None, &Some(_)) => {
|
2018-05-31 22:51:40 -07:00
|
|
|
panic!(
|
|
|
|
"the #[wasm_bindgen(version = \"...\")] attribute can only \
|
|
|
|
be used when `module = \"...\"` is also specified"
|
|
|
|
);
|
2018-04-25 07:26:33 -07:00
|
|
|
}
|
|
|
|
(&None, &None) => {}
|
|
|
|
}
|
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
|
|
|
shared::Import {
|
|
|
|
module: self.module.clone(),
|
2018-04-25 07:26:33 -07:00
|
|
|
version: self.version.clone(),
|
2018-05-21 07:29:34 -07:00
|
|
|
js_namespace: self.js_namespace.as_ref().map(|s| s.to_string()),
|
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
|
|
|
kind: self.kind.shared(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ImportKind {
|
2018-07-24 17:37:49 +01:00
|
|
|
/// Whether this type can be inside an `impl` block.
|
2018-05-11 08:28:09 -07:00
|
|
|
pub fn fits_on_impl(&self) -> bool {
|
|
|
|
match *self {
|
|
|
|
ImportKind::Function(_) => true,
|
|
|
|
ImportKind::Static(_) => false,
|
|
|
|
ImportKind::Type(_) => false,
|
2018-07-08 22:09:00 -04:00
|
|
|
ImportKind::Enum(_) => false,
|
2018-05-11 08:28:09 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
fn shared(&self) -> shared::ImportKind {
|
|
|
|
match *self {
|
|
|
|
ImportKind::Function(ref f) => shared::ImportKind::Function(f.shared()),
|
|
|
|
ImportKind::Static(ref f) => shared::ImportKind::Static(f.shared()),
|
|
|
|
ImportKind::Type(ref f) => shared::ImportKind::Type(f.shared()),
|
2018-07-08 22:09:00 -04:00
|
|
|
ImportKind::Enum(ref f) => shared::ImportKind::Enum(f.shared()),
|
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
|
|
|
}
|
2017-12-18 12:39:14 -08:00
|
|
|
}
|
2017-12-14 19:31:01 -08:00
|
|
|
}
|
2018-02-05 14:24:25 -08:00
|
|
|
|
2018-03-21 09:55:16 -07:00
|
|
|
impl ImportFunction {
|
2018-07-24 17:37:49 +01:00
|
|
|
/// If the rust object has a `fn xxx(&self) -> MyType` method, get the name for a getter in
|
|
|
|
/// javascript (in this case `xxx`, so you can write `val = obj.xxx`)
|
2018-07-07 10:20:31 -07:00
|
|
|
fn infer_getter_property(&self) -> String {
|
2018-05-21 07:29:34 -07:00
|
|
|
self.function.name.to_string()
|
2018-02-14 13:16:02 -08:00
|
|
|
}
|
|
|
|
|
2018-07-24 17:37:49 +01:00
|
|
|
/// If the rust object has a `fn set_xxx(&mut self, MyType)` style method, get the name
|
|
|
|
/// for a setter in javascript (in this case `xxx`, so you can write `obj.xxx = val`)
|
2018-07-07 10:20:31 -07:00
|
|
|
fn infer_setter_property(&self) -> String {
|
2018-05-21 07:29:34 -07:00
|
|
|
let name = self.function.name.to_string();
|
2018-02-14 13:16:02 -08:00
|
|
|
assert!(name.starts_with("set_"), "setters must start with `set_`");
|
|
|
|
name[4..].to_string()
|
|
|
|
}
|
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
|
|
|
|
|
|
|
fn shared(&self) -> shared::ImportFunction {
|
2018-07-07 10:20:31 -07:00
|
|
|
let method = match self.kind {
|
2018-06-14 22:48:32 -07:00
|
|
|
ImportFunctionKind::Method {
|
|
|
|
ref class,
|
|
|
|
ref kind,
|
|
|
|
..
|
|
|
|
} => {
|
|
|
|
let kind = match kind {
|
|
|
|
MethodKind::Constructor => shared::MethodKind::Constructor,
|
2018-07-07 10:20:31 -07:00
|
|
|
MethodKind::Operation(Operation { is_static, kind }) => {
|
|
|
|
let is_static = *is_static;
|
|
|
|
let kind = match kind {
|
|
|
|
OperationKind::Regular => shared::OperationKind::Regular,
|
|
|
|
OperationKind::Getter(g) => {
|
|
|
|
let g = g.as_ref().map(|g| g.to_string());
|
|
|
|
shared::OperationKind::Getter(
|
|
|
|
g.unwrap_or_else(|| self.infer_getter_property()),
|
|
|
|
)
|
|
|
|
}
|
|
|
|
OperationKind::Setter(s) => {
|
|
|
|
let s = s.as_ref().map(|s| s.to_string());
|
|
|
|
shared::OperationKind::Setter(
|
|
|
|
s.unwrap_or_else(|| self.infer_setter_property()),
|
|
|
|
)
|
|
|
|
}
|
|
|
|
};
|
|
|
|
shared::MethodKind::Operation(shared::Operation { is_static, kind })
|
|
|
|
}
|
2018-06-14 22:48:32 -07:00
|
|
|
};
|
2018-07-07 10:20:31 -07:00
|
|
|
Some(shared::MethodData {
|
2018-06-14 22:48:32 -07:00
|
|
|
class: class.clone(),
|
|
|
|
kind,
|
2018-07-07 10:20:31 -07:00
|
|
|
})
|
2018-06-14 22:48:32 -07:00
|
|
|
}
|
2018-07-07 10:20:31 -07:00
|
|
|
ImportFunctionKind::Normal => None,
|
|
|
|
};
|
2018-06-14 22:48:32 -07:00
|
|
|
|
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
|
|
|
shared::ImportFunction {
|
2018-05-21 07:29:34 -07:00
|
|
|
shim: self.shim.to_string(),
|
2018-07-07 10:20:31 -07:00
|
|
|
catch: self.catch,
|
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
|
|
|
method,
|
2018-07-07 10:20:31 -07:00
|
|
|
structural: self.structural,
|
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
|
|
|
function: self.function.shared(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ImportStatic {
|
|
|
|
fn shared(&self) -> shared::ImportStatic {
|
|
|
|
shared::ImportStatic {
|
2018-05-21 07:29:34 -07:00
|
|
|
name: self.js_name.to_string(),
|
|
|
|
shim: self.shim.to_string(),
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ImportType {
|
|
|
|
fn shared(&self) -> shared::ImportType {
|
2018-05-31 22:51:40 -07:00
|
|
|
shared::ImportType {}
|
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
|
|
|
}
|
2018-02-06 07:56:14 -08:00
|
|
|
}
|
|
|
|
|
2018-07-08 22:09:00 -04:00
|
|
|
impl ImportEnum {
|
|
|
|
fn shared(&self) -> shared::ImportEnum {
|
|
|
|
shared::ImportEnum {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-07 16:41:33 -08:00
|
|
|
impl Struct {
|
2018-04-19 16:49:46 -07:00
|
|
|
fn shared(&self) -> shared::Struct {
|
|
|
|
shared::Struct {
|
2018-05-21 07:29:34 -07:00
|
|
|
name: self.name.to_string(),
|
2018-04-19 16:49:46 -07:00
|
|
|
fields: self.fields.iter().map(|s| s.shared()).collect(),
|
2018-06-15 11:20:56 -05:00
|
|
|
comments: self.comments.clone(),
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl StructField {
|
|
|
|
fn shared(&self) -> shared::StructField {
|
|
|
|
shared::StructField {
|
2018-05-21 07:29:34 -07:00
|
|
|
name: self.name.to_string(),
|
2018-07-07 10:20:31 -07:00
|
|
|
readonly: self.readonly,
|
2018-06-15 11:20:56 -05:00
|
|
|
comments: self.comments.clone(),
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
2018-02-05 14:24:25 -08:00
|
|
|
}
|
|
|
|
}
|