2018-07-19 14:57:04 -05:00
|
|
|
#![doc(html_root_url = "https://docs.rs/wasm-bindgen-shared/0.2")]
|
|
|
|
|
2017-12-14 19:31:01 -08:00
|
|
|
#[macro_use]
|
|
|
|
extern crate serde_derive;
|
2018-02-06 16:06:21 -08:00
|
|
|
|
2018-08-30 13:26:07 -07:00
|
|
|
// The schema is so unstable right now we just force it to change whenever this
|
|
|
|
// package's version changes, which happens on all publishes.
|
|
|
|
pub const SCHEMA_VERSION: &str = env!("CARGO_PKG_VERSION");
|
2017-12-14 19:31:01 -08:00
|
|
|
|
2018-04-19 13:36:59 -07:00
|
|
|
#[derive(Deserialize)]
|
|
|
|
pub struct ProgramOnlySchema {
|
|
|
|
pub schema_version: String,
|
|
|
|
pub version: 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
|
|
|
#[derive(Deserialize, Serialize)]
|
2017-12-18 12:39:14 -08:00
|
|
|
pub struct Program {
|
2018-02-07 16:41:33 -08:00
|
|
|
pub exports: Vec<Export>,
|
2018-02-22 12:01:38 +01:00
|
|
|
pub enums: Vec<Enum>,
|
2018-03-21 09:55:16 -07:00
|
|
|
pub imports: Vec<Import>,
|
2018-04-19 16:49:46 -07:00
|
|
|
pub structs: Vec<Struct>,
|
2018-03-01 19:32:05 -08:00
|
|
|
pub version: String,
|
2018-03-05 20:05:44 -08:00
|
|
|
pub schema_version: String,
|
2017-12-18 12:39:14 -08: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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-02-06 07:56:14 -08:00
|
|
|
pub struct Import {
|
2018-03-21 09:55:16 -07:00
|
|
|
pub module: Option<String>,
|
2018-03-22 16:59:48 -07:00
|
|
|
pub js_namespace: Option<String>,
|
2018-03-21 09:55:16 -07:00
|
|
|
pub kind: ImportKind,
|
|
|
|
}
|
|
|
|
|
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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-03-21 09:55:16 -07:00
|
|
|
#[serde(tag = "kind", rename_all = "lowercase")]
|
|
|
|
pub enum ImportKind {
|
|
|
|
Function(ImportFunction),
|
|
|
|
Static(ImportStatic),
|
|
|
|
Type(ImportType),
|
2018-07-08 22:09:00 -04:00
|
|
|
Enum(ImportEnum),
|
2018-03-21 09:55:16 -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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-03-21 09:55:16 -07:00
|
|
|
pub struct ImportFunction {
|
2018-03-22 19:05:14 -07:00
|
|
|
pub shim: String,
|
2018-02-07 16:41:33 -08:00
|
|
|
pub catch: bool,
|
2018-08-18 22:15:29 +01:00
|
|
|
pub variadic: bool,
|
2018-06-14 22:48:32 -07:00
|
|
|
pub method: Option<MethodData>,
|
2018-03-22 17:37:27 -07:00
|
|
|
pub structural: bool,
|
2018-06-14 22:48:32 -07:00
|
|
|
pub function: Function,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub struct MethodData {
|
2018-09-17 14:01:53 -07:00
|
|
|
pub class: String,
|
2018-06-14 22:48:32 -07:00
|
|
|
pub kind: MethodKind,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub enum MethodKind {
|
|
|
|
Constructor,
|
2018-07-07 10:20:31 -07:00
|
|
|
Operation(Operation),
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub struct Operation {
|
|
|
|
pub is_static: bool,
|
|
|
|
pub kind: OperationKind,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub enum OperationKind {
|
|
|
|
Regular,
|
|
|
|
Getter(String),
|
|
|
|
Setter(String),
|
2018-08-07 00:06:04 +03:00
|
|
|
IndexingGetter,
|
|
|
|
IndexingSetter,
|
|
|
|
IndexingDeleter,
|
2018-02-05 14:24:25 -08: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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-03-21 09:55:16 -07:00
|
|
|
pub struct ImportStatic {
|
2018-03-21 08:09:59 -07:00
|
|
|
pub name: String,
|
2018-03-22 19:05:14 -07:00
|
|
|
pub shim: String,
|
2018-03-21 08:09:59 -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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-08-04 09:41:59 -07:00
|
|
|
pub struct ImportType {
|
|
|
|
pub name: String,
|
|
|
|
pub instanceof_shim: String,
|
|
|
|
}
|
2018-03-21 09:55:16 -07:00
|
|
|
|
2018-07-08 22:09:00 -04:00
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub struct ImportEnum {}
|
|
|
|
|
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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-02-07 16:41:33 -08:00
|
|
|
pub struct Export {
|
|
|
|
pub class: Option<String>,
|
|
|
|
pub method: bool,
|
2018-06-28 20:09:11 -05:00
|
|
|
pub consumed: bool,
|
2018-04-14 16:41:41 +02:00
|
|
|
pub constructor: Option<String>,
|
2017-12-18 12:39:14 -08:00
|
|
|
pub function: Function,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2017-12-18 12:39:14 -08: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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-02-22 12:01:38 +01:00
|
|
|
pub struct Enum {
|
|
|
|
pub name: String,
|
|
|
|
pub variants: Vec<EnumVariant>,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2018-02-22 12:01:38 +01: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
|
|
|
#[derive(Deserialize, Serialize)]
|
2018-02-22 12:01:38 +01:00
|
|
|
pub struct EnumVariant {
|
2018-02-23 14:17:53 +01:00
|
|
|
pub name: String,
|
2018-06-14 22:48:32 -07:00
|
|
|
pub value: u32,
|
2018-02-22 12:01:38 +01: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
|
|
|
#[derive(Deserialize, Serialize)]
|
2017-12-14 19:31:01 -08:00
|
|
|
pub struct Function {
|
|
|
|
pub name: String,
|
2018-02-06 16:06:21 -08:00
|
|
|
}
|
|
|
|
|
2018-04-19 16:49:46 -07:00
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub struct Struct {
|
|
|
|
pub name: String,
|
|
|
|
pub fields: Vec<StructField>,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Deserialize, Serialize)]
|
|
|
|
pub struct StructField {
|
|
|
|
pub name: String,
|
2018-04-20 10:56:10 -07:00
|
|
|
pub readonly: bool,
|
2018-06-15 11:20:56 -05:00
|
|
|
pub comments: Vec<String>,
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
|
|
|
|
2018-03-28 01:22:31 +02:00
|
|
|
pub fn new_function(struct_name: &str) -> String {
|
|
|
|
let mut name = format!("__wbg_");
|
2018-06-14 22:48:32 -07:00
|
|
|
name.extend(struct_name.chars().flat_map(|s| s.to_lowercase()));
|
2018-03-28 01:22:31 +02:00
|
|
|
name.push_str("_new");
|
2018-06-14 22:48:32 -07:00
|
|
|
return name;
|
2018-03-28 01:22:31 +02:00
|
|
|
}
|
|
|
|
|
2018-02-06 07:56:14 -08:00
|
|
|
pub fn free_function(struct_name: &str) -> String {
|
2018-02-06 11:54:40 -08:00
|
|
|
let mut name = format!("__wbg_");
|
2018-06-14 22:48:32 -07:00
|
|
|
name.extend(struct_name.chars().flat_map(|s| s.to_lowercase()));
|
2018-02-06 07:56:14 -08:00
|
|
|
name.push_str("_free");
|
2018-06-14 22:48:32 -07:00
|
|
|
return name;
|
2017-12-18 14:31:01 -08:00
|
|
|
}
|
|
|
|
|
2018-02-06 07:56:14 -08:00
|
|
|
pub fn free_function_export_name(function_name: &str) -> String {
|
|
|
|
function_name.to_string()
|
2017-12-18 14:31:01 -08:00
|
|
|
}
|
|
|
|
|
2018-02-06 07:56:14 -08:00
|
|
|
pub fn struct_function_export_name(struct_: &str, f: &str) -> String {
|
|
|
|
let mut name = struct_
|
|
|
|
.chars()
|
|
|
|
.flat_map(|s| s.to_lowercase())
|
|
|
|
.collect::<String>();
|
|
|
|
name.push_str("_");
|
|
|
|
name.push_str(f);
|
2018-06-14 22:48:32 -07:00
|
|
|
return name;
|
2017-12-14 21:55:21 -08:00
|
|
|
}
|
|
|
|
|
2018-04-19 16:49:46 -07:00
|
|
|
pub fn struct_field_get(struct_: &str, f: &str) -> String {
|
|
|
|
let mut name = String::from("__wbg_get_");
|
2018-06-14 22:48:32 -07:00
|
|
|
name.extend(struct_.chars().flat_map(|s| s.to_lowercase()));
|
2018-04-19 16:49:46 -07:00
|
|
|
name.push_str("_");
|
|
|
|
name.push_str(f);
|
2018-06-14 22:48:32 -07:00
|
|
|
return name;
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn struct_field_set(struct_: &str, f: &str) -> String {
|
|
|
|
let mut name = String::from("__wbg_set_");
|
2018-06-14 22:48:32 -07:00
|
|
|
name.extend(struct_.chars().flat_map(|s| s.to_lowercase()));
|
2018-04-19 16:49:46 -07:00
|
|
|
name.push_str("_");
|
|
|
|
name.push_str(f);
|
2018-06-14 22:48:32 -07:00
|
|
|
return name;
|
2018-04-19 16:49:46 -07:00
|
|
|
}
|
|
|
|
|
2018-03-01 19:19:12 -08:00
|
|
|
pub fn version() -> String {
|
|
|
|
let mut v = env!("CARGO_PKG_VERSION").to_string();
|
|
|
|
if let Some(s) = option_env!("WBG_VERSION") {
|
|
|
|
v.push_str(" (");
|
|
|
|
v.push_str(s);
|
|
|
|
v.push_str(")");
|
|
|
|
}
|
2018-06-14 22:48:32 -07:00
|
|
|
return v;
|
2018-03-01 19:19:12 -08:00
|
|
|
}
|