wasm-bindgen/tests/all/main.rs

387 lines
11 KiB
Rust
Raw Normal View History

2017-12-15 06:31:01 +03:00
extern crate wasm_bindgen_cli_support as cli;
use std::env;
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-30 08:20:38 +03:00
use std::fs::{self, File};
use std::io::{self, Write, Read};
2017-12-15 06:31:01 +03:00
use std::path::{PathBuf, Path};
use std::process::{Command, Stdio};
use std::sync::{Once, ONCE_INIT};
2017-12-15 06:31:01 +03:00
use std::sync::atomic::*;
use std::time::Instant;
2017-12-15 06:31:01 +03:00
2017-12-19 01:31:01 +03:00
static CNT: AtomicUsize = ATOMIC_USIZE_INIT;
thread_local!(static IDX: usize = CNT.fetch_add(1, Ordering::SeqCst));
struct Project {
2017-12-15 06:31:01 +03:00
files: Vec<(String, String)>,
debug: bool,
node: bool,
no_std: bool,
serde: bool,
rlib: bool,
node_args: Vec<String>,
deps: Vec<String>,
2017-12-15 06:31:01 +03:00
}
fn project() -> Project {
2017-12-15 06:31:01 +03:00
let dir = Path::new(env!("CARGO_MANIFEST_DIR"));
let mut lockfile = String::new();
fs::File::open(&dir.join("Cargo.lock")).unwrap()
.read_to_string(&mut lockfile).unwrap();
2017-12-15 06:31:01 +03:00
Project {
debug: true,
node: false,
no_std: false,
serde: false,
rlib: false,
deps: Vec::new(),
node_args: Vec::new(),
2017-12-15 06:31:01 +03:00
files: vec![
("Cargo.lock".to_string(), lockfile),
("run.js".to_string(), r#"
import * as process from "process";
let wasm = import('./out');
const test = import("./test");
Promise.all([test, wasm]).then(results => {
let [test, wasm] = results;
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-30 08:20:38 +03:00
test.test();
if (wasm.assertStackEmpty)
wasm.assertStackEmpty();
if (wasm.assertSlabEmpty)
wasm.assertSlabEmpty();
}).catch(error => {
console.error(error);
process.exit(1);
2017-12-15 06:31:01 +03:00
});
"#.to_string()),
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-30 08:20:38 +03:00
2018-03-30 00:49:36 +03:00
("run-node.js".to_string(), r#"
require("./test").test();
"#.to_string()),
("webpack.config.js".to_string(), r#"
const path = require('path');
module.exports = {
entry: './run.js',
mode: "development",
devtool: "source-map",
module: {
rules: [
{
test: /\.ts$/,
use: 'ts-loader',
exclude: /node_modules/
}
]
},
resolve: {
extensions: [ '.ts', '.js', '.wasm' ]
},
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, '.')
},
target: 'node'
};
"#.to_string()),
("tsconfig.json".to_string(), r#"
{
"compilerOptions": {
"noEmitOnError": true,
"noImplicitAny": true,
"noImplicitThis": true,
"noUnusedParameters": true,
"noUnusedLocals": true,
"noImplicitReturns": true,
"strictFunctionTypes": true,
"strictNullChecks": true,
"alwaysStrict": true,
"strict": true,
"target": "es5",
"lib": ["es2015"]
}
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-30 08:20:38 +03:00
}
"#.to_string()),
2017-12-15 06:31:01 +03:00
],
}
}
fn root() -> PathBuf {
2017-12-15 06:31:01 +03:00
let idx = IDX.with(|x| *x);
let mut me = env::current_exe().unwrap();
me.pop(); // chop off exe name
me.pop(); // chop off `deps`
me.pop(); // chop off `debug` / `release`
me.push("generated-tests");
me.push(&format!("test{}", idx));
return me
}
fn assert_bigint_support() -> Option<&'static str> {
static BIGINT_SUPPORED: AtomicUsize = ATOMIC_USIZE_INIT;
static INIT: Once = ONCE_INIT;
INIT.call_once(|| {
let mut cmd = Command::new("node");
cmd.arg("-e").arg("BigInt");
cmd.stdin(Stdio::null())
.stdout(Stdio::piped())
.stderr(Stdio::piped());
if cmd.status().unwrap().success() {
BIGINT_SUPPORED.store(1, Ordering::SeqCst);
return
}
cmd.arg("--harmony-bigint");
if cmd.status().unwrap().success() {
BIGINT_SUPPORED.store(2, Ordering::SeqCst);
return
}
});
match BIGINT_SUPPORED.load(Ordering::SeqCst) {
1 => return None,
2 => return Some("--harmony-bigint"),
_ => {
panic!("the version of node.js that is installed for these tests \
does not support `BigInt`, you may wish to try installing \
node 10 to fix this")
}
}
}
2017-12-15 06:31:01 +03:00
impl Project {
fn file(&mut self, name: &str, contents: &str) -> &mut Project {
2017-12-15 06:31:01 +03:00
self.files.push((name.to_string(), contents.to_string()));
self
}
fn debug(&mut self, debug: bool) -> &mut Project {
self.debug = debug;
self
}
fn node(&mut self, node: bool) -> &mut Project {
self.node = node;
self
}
fn no_std(&mut self, no_std: bool) -> &mut Project {
self.no_std = no_std;
self
}
fn serde(&mut self, serde: bool) -> &mut Project {
self.serde = serde;
self
}
fn rlib(&mut self, rlib: bool) -> &mut Project {
self.rlib = rlib;
self
}
fn depend(&mut self, dep: &str) -> &mut Project {
self.deps.push(dep.to_string());
self
}
fn add_local_dependency(&mut self, name: &str, path: &str) -> &mut Project {
self.deps.push(format!("{} = {{ path = '{}' }}", name, path));
self
}
fn crate_name(&self) -> String {
format!("test{}", IDX.with(|x| *x))
}
fn requires_bigint(&mut self) -> &mut Project {
if let Some(arg) = assert_bigint_support() {
self.node_args.push(arg.to_string());
}
self
}
fn build(&mut self) -> (PathBuf, PathBuf) {
let mut manifest = format!(r#"
[package]
name = "test{}"
version = "0.0.1"
authors = []
[workspace]
[lib]
"#, IDX.with(|x| *x));
if !self.rlib {
manifest.push_str("crate-type = [\"cdylib\"]\n");
}
manifest.push_str("[dependencies]\n");
for dep in self.deps.iter() {
manifest.push_str(dep);
manifest.push_str("\n");
}
manifest.push_str("wasm-bindgen = { path = '");
manifest.push_str(env!("CARGO_MANIFEST_DIR"));
manifest.push_str("'");
if self.no_std {
manifest.push_str(", default-features = false");
}
if self.serde {
manifest.push_str(", features = ['serde-serialize']");
}
manifest.push_str(" }\n");
self.files.push(("Cargo.toml".to_string(), manifest));
2017-12-15 06:31:01 +03:00
let root = root();
drop(fs::remove_dir_all(&root));
for &(ref file, ref contents) in self.files.iter() {
let dst = root.join(file);
fs::create_dir_all(dst.parent().unwrap()).unwrap();
fs::File::create(&dst).unwrap().write_all(contents.as_ref()).unwrap();
}
let target_dir = root.parent().unwrap() // chop off test name
.parent().unwrap(); // chop off `generated-tests`
(root.clone(), target_dir.to_path_buf())
}
fn test(&mut self) {
let (root, target_dir) = self.build();
2017-12-15 06:31:01 +03:00
let mut cmd = Command::new("cargo");
cmd.arg("build")
.arg("--target")
.arg("wasm32-unknown-unknown")
.current_dir(&root)
.env("CARGO_TARGET_DIR", &target_dir)
// Catch any warnings in generated code because we don't want any
.env("RUSTFLAGS", "-Dwarnings");
2017-12-15 06:31:01 +03:00
run(&mut cmd, "cargo");
2017-12-19 01:31:01 +03:00
let idx = IDX.with(|x| *x);
2018-03-31 12:35:09 +03:00
let out = target_dir.join(&format!("wasm32-unknown-unknown/debug/test{}.wasm", idx));
2017-12-15 06:31:01 +03:00
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-30 08:20:38 +03:00
let as_a_module = root.join("out.wasm");
fs::copy(&out, &as_a_module).unwrap();
let res = cli::Bindgen::new()
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-30 08:20:38 +03:00
.input_path(&as_a_module)
.typescript(true)
.nodejs(self.node)
.debug(self.debug)
.generate(&root);
if let Err(e) = res {
for e in e.causes() {
println!("- {}", e);
}
panic!("failed");
}
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-30 08:20:38 +03:00
let mut wasm = Vec::new();
File::open(root.join("out_bg.wasm")).unwrap()
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-30 08:20:38 +03:00
.read_to_end(&mut wasm).unwrap();
let obj = cli::wasm2es6js::Config::new()
.base64(true)
.generate(&wasm)
.expect("failed to convert wasm to js");
File::create(root.join("out_bg.d.ts")).unwrap()
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-30 08:20:38 +03:00
.write_all(obj.typescript().as_bytes()).unwrap();
// move files from the root into each test, it looks like this may be
// needed for webpack to work well when invoked concurrently.
fs::hard_link("package.json", root.join("package.json")).unwrap();
if !Path::new("node_modules").exists() {
panic!("\n\nfailed to find `node_modules`, have you run `npm install` yet?\n\n");
2018-04-03 17:07:14 +03:00
}
fs::hard_link("package-lock.json", root.join("package-lock.json")).unwrap();
let cwd = env::current_dir().unwrap();
symlink_dir(&cwd.join("node_modules"), &root.join("node_modules")).unwrap();
2017-12-15 06:31:01 +03:00
if self.node {
let mut cmd = Command::new("node");
cmd.args(&self.node_args);
2018-03-30 00:49:36 +03:00
cmd.arg(root.join("run-node.js"))
.current_dir(&root);
run(&mut cmd, "node");
} else {
let mut cmd = if cfg!(windows) {
let mut c = Command::new("cmd");
c.arg("/c");
c.arg("npm");
c
} else {
Command::new("npm")
};
cmd.arg("run").arg("run-webpack").current_dir(&root);
run(&mut cmd, "npm");
let mut cmd = Command::new("node");
cmd.args(&self.node_args);
cmd.arg(root.join("bundle.js"))
.current_dir(&root);
run(&mut cmd, "node");
}
2017-12-15 06:31:01 +03:00
}
}
#[cfg(unix)]
fn symlink_dir(a: &Path, b: &Path) -> io::Result<()> {
use std::os::unix::fs::symlink;
symlink(a, b)
}
#[cfg(windows)]
fn symlink_dir(a: &Path, b: &Path) -> io::Result<()> {
use std::os::windows::fs::symlink_dir;
symlink_dir(a, b)
}
2017-12-15 06:31:01 +03:00
fn run(cmd: &mut Command, program: &str) {
println!("···················································");
2017-12-15 06:31:01 +03:00
println!("running {:?}", cmd);
let start = Instant::now();
2017-12-15 06:31:01 +03:00
let output = match cmd.output() {
Ok(output) => output,
Err(err) => panic!("failed to spawn `{}`: {}", program, err),
};
println!("exit: {}", output.status);
let dur = start.elapsed();
println!("dur: {}.{:03}ms", dur.as_secs(), dur.subsec_nanos() / 1_000_000);
2017-12-15 06:31:01 +03:00
if output.stdout.len() > 0 {
println!("stdout ---\n{}", String::from_utf8_lossy(&output.stdout));
}
if output.stderr.len() > 0 {
println!("stderr ---\n{}", String::from_utf8_lossy(&output.stderr));
}
assert!(output.status.success());
}
mod api;
mod classes;
mod closures;
mod dependencies;
mod enums;
mod import_class;
mod imports;
mod jsobjects;
mod math;
mod node;
mod non_debug;
mod simple;
mod slice;
mod structural;
mod non_wasm;
mod u64;
mod char;
mod webidl;