wasm-bindgen/crates/macro/ui-tests/start-function.rs

#![crate_type = "rlib"]

extern crate wasm_bindgen;

use wasm_bindgen::prelude::*;

#[wasm_bindgen(start)]
pub fn foo() {}

#[wasm_bindgen(start)]
pub fn foo2(x: u32) {}

#[wasm_bindgen(start)]
pub fn foo3<T>() {}
Update UI tests 2019-01-02 19:35:01 +03:00			`#![crate_type = "rlib"]`

Add a `#[wasm_bindgen(start)]` attribute This commit adds a new attribute to `#[wasm_bindgen]`: `start`. The `start` attribute can be used to indicate that a function should be executed when the module is loaded, configuring the `start` function of the wasm executable. While this doesn't necessarily literally configure the `start` section, it does its best! Only one crate in a crate graph may indicate `#[wasm_bindgen(start)]`, so it's not recommended to be used in libraries but only end-user applications. Currently this still must be used with the `crate-type = ["cdylib"]` annotation in `Cargo.toml`. The implementation here is somewhat tricky because of the circular dependency between our generated JS and the wasm file that we emit. This circular dependency makes running initialization routines (like the `start` shim) particularly fraught with complications because one may need to run before the other but bundlers may not necessarily respect it. Workarounds have been implemented for various emission strategies, for example calling the start function directly after exports are wired up with `--no-modules` and otherwise working around what appears to be a Webpack bug with initializers running in a different order than we'd like. In any case, this in theory doesn't show up to the end user! Closes #74 2018-11-28 20:25:51 +03:00			`extern crate wasm_bindgen;`

			`use wasm_bindgen::prelude::*;`

			`#[wasm_bindgen(start)]`
			`pub fn foo() {}`

			`#[wasm_bindgen(start)]`
			`pub fn foo2(x: u32) {}`

			`#[wasm_bindgen(start)]`
			`pub fn foo3<T>() {}`