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

error: the start function cannot have arguments
 --> $DIR/start-function.rs:7:13
  |
7 | pub fn foo2(x: u32) {}
  |             ^^^^^^

error: the start function cannot have generics
  --> $DIR/start-function.rs:10:12
   |
10 | pub fn foo3<T>() {}
   |            ^^^
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 09:25:51 -08:00			`error: the start function cannot have arguments`
Migrate to `trybuild` from `compiletest` This migrates our UI tests to the recently published `trybuild` crate which should hopefully be a bit more robust than `compiletest` over time! 2019-05-15 14:46:03 -07:00			`--> $DIR/start-function.rs:7:13`
			`\|`
			`7 \| pub fn foo2(x: u32) {}`
			`\| ^^^^^^`
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 09:25:51 -08:00
			`error: the start function cannot have generics`
Migrate to `trybuild` from `compiletest` This migrates our UI tests to the recently published `trybuild` crate which should hopefully be a bit more robust than `compiletest` over time! 2019-05-15 14:46:03 -07:00			`--> $DIR/start-function.rs:10:12`
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 09:25:51 -08:00			`\|`
Migrate to `trybuild` from `compiletest` This migrates our UI tests to the recently published `trybuild` crate which should hopefully be a bit more robust than `compiletest` over time! 2019-05-15 14:46:03 -07:00			`10 \| pub fn foo3<T>() {}`
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 09:25:51 -08:00			`\| ^^^`