242 lines
6.9 KiB
Rust
Raw Normal View History

2017-12-14 19:31:01 -08:00
extern crate parity_wasm;
extern crate wasm_bindgen_shared as shared;
extern crate serde_json;
extern crate wasm_gc;
2017-12-14 19:31:01 -08:00
use std::char;
2017-12-14 19:31:01 -08:00
use std::fs::File;
use std::io::Write;
use std::ops::Deref;
use std::path::{Path, PathBuf};
use std::slice;
2017-12-14 19:31:01 -08:00
use parity_wasm::elements::*;
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
mod js;
pub mod wasm2es6js;
2017-12-18 12:39:14 -08:00
2017-12-14 19:31:01 -08:00
pub struct Bindgen {
path: Option<PathBuf>,
2017-12-14 21:55:21 -08:00
nodejs: bool,
nodejs_runtime_detect: bool,
debug: bool,
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
typescript: bool,
2017-12-14 19:31:01 -08:00
}
2018-03-05 19:25:50 -08:00
#[derive(Debug)]
pub struct Error(String);
impl<E: std::error::Error> From<E> for Error {
fn from(e: E) -> Error {
Error(e.to_string())
}
}
2017-12-14 19:31:01 -08:00
impl Bindgen {
pub fn new() -> Bindgen {
Bindgen {
path: None,
2017-12-14 21:55:21 -08:00
nodejs: false,
nodejs_runtime_detect: false,
debug: false,
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
typescript: false,
2017-12-14 19:31:01 -08:00
}
}
pub fn input_path<P: AsRef<Path>>(&mut self, path: P) -> &mut Bindgen {
self.path = Some(path.as_ref().to_path_buf());
self
}
2017-12-14 21:55:21 -08:00
pub fn nodejs(&mut self, node: bool) -> &mut Bindgen {
self.nodejs = node;
self
}
pub fn nodejs_runtime_detect(&mut self, detect: bool) -> &mut Bindgen {
self.nodejs_runtime_detect = detect;
self
}
pub fn debug(&mut self, debug: bool) -> &mut Bindgen {
self.debug = debug;
self
}
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
pub fn typescript(&mut self, typescript: bool) -> &mut Bindgen {
self.typescript = typescript;
self
}
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
pub fn generate<P: AsRef<Path>>(&mut self, path: P) -> Result<(), Error> {
self._generate(path.as_ref())
}
fn _generate(&mut self, out_dir: &Path) -> Result<(), Error> {
2017-12-14 19:31:01 -08:00
let input = match self.path {
Some(ref path) => path,
None => panic!("must have a path input for now"),
};
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
let stem = input.file_stem().unwrap().to_str().unwrap();
2017-12-14 19:31:01 -08:00
let mut module = parity_wasm::deserialize_file(input).map_err(|e| {
2018-03-05 19:25:50 -08:00
Error(format!("{:?}", e))
2017-12-14 19:31:01 -08:00
})?;
let programs = extract_programs(&mut module);
let (js, ts) = {
let mut cx = js::Context {
globals: String::new(),
imports: String::new(),
typescript: format!("/* tslint:disable */\n"),
exposed_globals: Default::default(),
required_internal_exports: Default::default(),
imports_to_rewrite: Default::default(),
custom_type_names: Default::default(),
imported_names: Default::default(),
exported_classes: Default::default(),
config: &self,
module: &mut module,
};
for program in programs.iter() {
cx.add_custom_type_names(program);
}
for program in programs.iter() {
js::SubContext {
program,
cx: &mut cx,
}.generate();
}
cx.finalize(stem)
};
Rewrite wasm-bindgen with ES6 modules in mind This commit is a mostly-rewrite of the `wasm-bindgen` tool. After some recent discussions it's clear that the previous model wasn't quite going to cut it, and this iteration is one which primarily embraces ES6 modules and the idea that this is a polyfill for host bindings. The overall interface and functionality hasn't changed much but the underlying technology has now changed significantly. Previously `wasm-bindgen` would emit a JS file that acted as an ES6 module but had a bit of a wonky interface. It exposed an async function for instantiation of the wasm module, but that's the bundler's job, not ours! Instead this iteration views each input and output as a discrete ES6 module. The input wasm file is interpreted as "this *should* be an ES6 module with rich types" and the output is "well here's some ES6 modules that fulfill that contract". Notably the tool now replaces the original wasm ES6 module with a JS ES6 module that has the "rich interface". Additionally a second ES6 module is emitted (the actual wasm file) which imports and exports to the original ES6 module. This strategy is hoped to be much more amenable to bundlers and controlling how the wasm itself is instantiated. The emitted files files purely assume ES6 modules and should be able to work as-is once ES6 module integration for wasm is completed. Note that there aren't a ton of tools to pretend a wasm module is an ES6 module at the moment but those should be coming soon! In the meantime a local `wasm2es6js` hack was added to help make *something* work today. The README has also been updated with instructions for interacting with this model.
2018-01-29 21:20:38 -08:00
let js_path = out_dir.join(stem).with_extension("js");
File::create(&js_path).unwrap()
.write_all(js.as_bytes()).unwrap();
if self.typescript {
let ts_path = out_dir.join(stem).with_extension("d.ts");
File::create(&ts_path).unwrap()
.write_all(ts.as_bytes()).unwrap();
}
2017-12-14 19:31:01 -08:00
let wasm_path = out_dir.join(format!("{}_bg", stem)).with_extension("wasm");
let wasm_bytes = parity_wasm::serialize(module).map_err(|e| {
2018-03-05 19:25:50 -08:00
Error(format!("{:?}", e))
2017-12-14 19:31:01 -08:00
})?;
let bytes = wasm_gc::Config::new()
.demangle(false)
.gc(&wasm_bytes)?;
File::create(&wasm_path)?.write_all(&bytes)?;
2017-12-14 19:31:01 -08:00
Ok(())
}
}
fn extract_programs(module: &mut Module) -> Vec<shared::Program> {
let version = shared::version();
2017-12-14 19:31:01 -08:00
let data = module.sections_mut()
.iter_mut()
.filter_map(|s| {
match *s {
Section::Data(ref mut s) => Some(s),
_ => None,
}
})
.next();
2017-12-18 12:39:14 -08:00
let mut ret = Vec::new();
2017-12-14 19:31:01 -08:00
let data = match data {
Some(data) => data,
2017-12-18 12:39:14 -08:00
None => return ret,
2017-12-14 19:31:01 -08:00
};
for entry in data.entries_mut() {
let value = bytes_to_u32(entry.value_mut());
let mut value = &*value;
loop {
match value.iter().position(|i| i.0 == 0x30d97887) {
Some(i) => value = &value[i + 1..],
None => break,
}
if value.get(0).map(|c| c.0) != Some(0xd4182f61) {
continue
2017-12-14 19:31:01 -08:00
}
let cnt = value[1].0 as usize;
let (a, b) = value[2..].split_at(cnt);
value = b;
let json = a.iter()
.map(|i| char::from_u32(i.0).unwrap())
.collect::<String>();
let p: shared::Program = match serde_json::from_str(&json) {
2017-12-14 19:31:01 -08:00
Ok(f) => f,
Err(e) => {
panic!("failed to decode what looked like wasm-bindgen data: {}", e)
}
2017-12-14 19:31:01 -08:00
};
if p.schema_version != shared::SCHEMA_VERSION {
panic!("
it looks like the Rust project used to create this wasm file was linked against
a different version of wasm-bindgen than this binary:
rust wasm file: {}
this binary: {}
Currently the bindgen format is unstable enough that these two version must
exactly match, so it's required that these two version are kept in sync by
either updating the wasm-bindgen dependency or this binary. You should be able
to update the wasm-bindgen dependency with:
cargo update -p wasm-bindgen
or you can update the binary with
cargo install -f --git https://github.com/alexcrichton/wasm-bindgen
if this warning fails to go away though and you're not sure what to do feel free
to open an issue at https://github.com/alexcrichton/wasm-bindgen/issues!
",
p.version, version);
}
ret.push(p);
2017-12-14 19:31:01 -08:00
}
}
return ret
}
#[repr(packed)]
struct Unaligned(u32);
struct FutzWithAlign<'a> {
data: &'a mut Vec<u8>,
len: usize,
}
fn bytes_to_u32(a: &mut Vec<u8>) -> FutzWithAlign {
let prev_len = a.len();
// Data implicitly contains zeros after it and it looks like LLD exploits
// this. Pad our view into the vector with zeros to make sure that we read
// off everything when we iterate. After we're done iterating though we put
// this back as we found it, hence the newtype wrapper w/ a dtor.
while a.len() % 4 != 0 {
a.push(0);
}
FutzWithAlign { data: a, len: prev_len }
}
impl<'a> Deref for FutzWithAlign<'a> {
type Target = [Unaligned];
fn deref(&self) -> &[Unaligned] {
unsafe {
slice::from_raw_parts(self.data.as_ptr() as *const Unaligned,
self.data.len() / 4)
}
}
}
impl<'a> Drop for FutzWithAlign<'a> {
fn drop(&mut self) {
self.data.truncate(self.len);
}
}