wasm-bindgen/tests/all/classes.rs

476 lines
12 KiB
Rust
Raw Normal View History

use super::project;
2017-12-18 23:39:14 +03:00
#[test]
fn simple() {
project()
2017-12-18 23:39:14 +03:00
.file("src/lib.rs", r#"
2018-04-02 19:58:15 +03:00
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
2017-12-18 23:39:14 +03:00
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct Foo {
contents: u32,
}
2017-12-18 23:39:14 +03:00
#[wasm_bindgen]
impl Foo {
#[wasm_bindgen(constructor)]
pub fn new() -> Foo {
Foo::with_contents(0)
}
2017-12-18 23:39:14 +03:00
pub fn with_contents(a: u32) -> Foo {
Foo { contents: a }
}
2017-12-18 23:39:14 +03:00
pub fn add(&mut self, amt: u32) -> u32 {
self.contents += amt;
self.contents
2017-12-18 23:39:14 +03:00
}
}
"#)
.file("test.ts", r#"
2017-12-18 23:39:14 +03:00
import * as assert from "assert";
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
import { Foo } from "./out";
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
export function test() {
const r = Foo.new();
2017-12-18 23:39:14 +03:00
assert.strictEqual(r.add(0), 0);
assert.strictEqual(r.add(1), 1);
assert.strictEqual(r.add(1), 2);
2017-12-19 01:31:01 +03:00
r.free();
2017-12-18 23:39:14 +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
const r2 = Foo.with_contents(10);
2017-12-19 01:31:01 +03:00
assert.strictEqual(r2.add(1), 11);
assert.strictEqual(r2.add(2), 13);
assert.strictEqual(r2.add(3), 16);
r2.free();
const r3 = new Foo();
assert.strictEqual(r3.add(42), 42);
r3.free();
2017-12-19 01:31:01 +03:00
}
"#)
.test();
}
#[test]
fn strings() {
project()
2017-12-19 01:31:01 +03:00
.file("src/lib.rs", r#"
2018-04-02 19:58:15 +03:00
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
2017-12-19 01:31:01 +03:00
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct Foo {
name: u32,
}
2017-12-19 01:31:01 +03:00
#[wasm_bindgen]
pub struct Bar {
contents: String,
}
2017-12-19 01:31:01 +03:00
#[wasm_bindgen]
impl Foo {
pub fn new() -> Foo {
Foo { name: 0 }
}
2017-12-19 01:31:01 +03:00
pub fn set(&mut self, amt: u32) {
self.name = amt;
}
2017-12-19 01:31:01 +03:00
pub fn bar(&self, mix: &str) -> Bar {
Bar { contents: format!("foo-{}-{}", mix, self.name) }
2017-12-19 01:31:01 +03:00
}
}
2017-12-19 01:31:01 +03:00
#[wasm_bindgen]
impl Bar {
pub fn name(&self) -> String {
self.contents.clone()
2017-12-19 01:31:01 +03:00
}
}
"#)
.file("test.ts", r#"
2017-12-19 01:31:01 +03:00
import * as assert from "assert";
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
import { Foo } from "./out";
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
export function test() {
const r = Foo.new();
2017-12-19 01:31:01 +03:00
r.set(3);
let bar = r.bar('baz');
r.free();
assert.strictEqual(bar.name(), "foo-baz-3");
bar.free();
2017-12-18 23:39:14 +03:00
}
"#)
.test();
}
2017-12-19 01:44:09 +03:00
#[test]
fn exceptions() {
project()
2017-12-19 01:44:09 +03:00
.file("src/lib.rs", r#"
2018-04-02 19:58:15 +03:00
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
2017-12-19 01:44:09 +03:00
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct A {
}
#[wasm_bindgen]
impl A {
pub fn new() -> A {
A {}
}
pub fn foo(&self, _: &A) {
2017-12-19 01:44:09 +03:00
}
pub fn bar(&mut self, _: &mut A) {
}
}
#[wasm_bindgen]
pub struct B {
}
#[wasm_bindgen]
impl B {
pub fn new() -> B {
B {}
}
2017-12-19 01:44:09 +03:00
}
"#)
.file("test.js", r#"
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
import * as assert from "assert";
import { A, B } from "./out";
2017-12-19 01:44:09 +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
export function test() {
assert.throws(() => new A(), /cannot invoke `new` directly/);
let a = A.new();
2017-12-19 01:44:09 +03:00
a.free();
assert.throws(() => a.free(), /null pointer passed to rust/);
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 b = A.new();
b.foo(b);
assert.throws(() => b.bar(b), /recursive use of an object/);
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 c = A.new();
let d = B.new();
assert.throws(() => c.foo(d), /expected instance of A/);
d.free();
c.free();
};
"#)
.file("test.d.ts", r#"
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
export function test(): void;
"#)
.test();
}
#[test]
fn pass_one_to_another() {
project()
.file("src/lib.rs", r#"
2018-04-02 19:58:15 +03:00
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct A {}
#[wasm_bindgen]
impl A {
pub fn new() -> A {
A {}
}
pub fn foo(&self, _other: &B) {
}
pub fn bar(&self, _other: B) {
}
}
#[wasm_bindgen]
pub struct B {}
#[wasm_bindgen]
impl B {
pub fn new() -> B {
B {}
}
}
"#)
.file("test.ts", r#"
import { A, B } from "./out";
export function test() {
let a = A.new();
let b = B.new();
a.foo(b);
a.bar(b);
a.free();
}
"#)
.test();
}
#[test]
fn pass_into_js() {
project()
.file("src/lib.rs", r#"
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct Foo(i32);
#[wasm_bindgen]
impl Foo {
pub fn inner(&self) -> i32 {
self.0
}
}
#[wasm_bindgen(module = "./test")]
extern {
fn take_foo(foo: Foo);
}
#[wasm_bindgen]
pub fn run() {
take_foo(Foo(13));
}
"#)
.file("test.ts", r#"
import { run, Foo } from "./out";
import * as assert from "assert";
export function take_foo(foo: Foo) {
assert.strictEqual(foo.inner(), 13);
foo.free();
assert.throws(() => foo.free(), /null pointer passed to rust/);
}
export function test() {
run();
}
"#)
.test();
}
#[test]
fn issue_27() {
project()
.file("src/lib.rs", r#"
2018-04-02 19:58:15 +03:00
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct Context {}
#[wasm_bindgen]
impl Context {
pub fn parse(&self, expr: &str) -> Expr {
panic!()
}
pub fn eval(&self, expr: &Expr) -> f64 {
panic!()
}
pub fn set(&mut self, var: &str, val: f64) {
panic!()
}
}
#[wasm_bindgen]
pub struct Expr {}
#[wasm_bindgen]
pub fn context() -> Context {
Context {}
}
"#)
.file("test.ts", r#"
import { context } from "./out";
export function test() {
context();
}
"#)
.test();
}
#[test]
fn pass_into_js_as_js_class() {
project()
.file("src/lib.rs", r#"
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct Foo(i32);
#[wasm_bindgen]
impl Foo {
pub fn inner(&self) -> i32 {
self.0
}
}
#[wasm_bindgen(module = "./test")]
extern {
fn take_foo(foo: JsValue);
}
#[wasm_bindgen]
pub fn run() {
take_foo(Foo(13).into());
}
"#)
.file("test.ts", r#"
import { run, Foo } from "./out";
import * as assert from "assert";
export function take_foo(foo: any) {
assert(foo instanceof Foo);
assert.strictEqual(foo.inner(), 13);
foo.free();
}
export function test() {
run();
}
"#)
.test();
}
#[test]
fn constructors() {
project()
.file("src/lib.rs", r#"
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub fn cross_item_construction() -> Bar {
Bar::other_name(7, 8)
}
#[wasm_bindgen]
pub struct Foo {
number: u32,
}
#[wasm_bindgen]
impl Foo {
#[wasm_bindgen(constructor)]
pub fn new(number: u32) -> Foo {
Foo { number }
}
pub fn get_number(&self) -> u32 {
self.number
}
}
#[wasm_bindgen]
pub struct Bar {
number: u32,
number2: u32,
}
#[wasm_bindgen]
impl Bar {
#[wasm_bindgen(constructor)]
2018-04-14 17:41:41 +03:00
pub fn other_name(number: u32, number2: u32) -> Bar {
Bar { number, number2 }
}
pub fn get_sum(&self) -> u32 {
self.number + self.number2
}
}
"#)
.file("test.ts", r#"
import * as assert from "assert";
import { Foo, Bar, cross_item_construction } from "./out";
export function test() {
const foo = new Foo(1);
assert.strictEqual(foo.get_number(), 1);
foo.free();
const foo2 = Foo.new(2);
assert.strictEqual(foo2.get_number(), 2);
foo2.free();
const bar = new Bar(3, 4);
assert.strictEqual(bar.get_sum(), 7);
bar.free();
2018-04-14 17:41:41 +03:00
const bar2 = Bar.other_name(5, 6);
assert.strictEqual(bar2.get_sum(), 11);
bar2.free();
assert.strictEqual(cross_item_construction().get_sum(), 15);
}
"#)
.test();
}
#[test]
fn empty_structs() {
project()
.debug(false)
.file("src/lib.rs", r#"
#![feature(proc_macro, wasm_custom_section, wasm_import_module)]
extern crate wasm_bindgen;
use wasm_bindgen::prelude::*;
#[wasm_bindgen]
pub struct MissingClass {}
#[wasm_bindgen]
pub struct Other {}
#[wasm_bindgen]
impl Other { pub fn return_a_value() -> MissingClass { MissingClass {} } }
"#)
.file("test.ts", r#"
import { Other } from "./out";
export function test() {
Other.return_a_value();
}
"#)
.test();
}