Producing wasm-binary if there's main.rs

[akritrime]

Currently, the only way to execute rust code is via exposing a function and then calling it on js side. It would be nice to be able to do something like this:
main.rs

#![feature(proc_macro)]

extern crate wasm_bindgen;

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);
}

fn main() {
    log("Hello from Rust");
}

Then using the cli to generate the required js and including the js directly in the html to execute it, instead of going through an intermediate state of needing to manually write another js file.

[alexcrichton]

This is sort of related to https://github.com/rust-lang-nursery/rust-wasm/issues/18 as the wasm feature here we'd leverage is the start section but the Rust compiler, as of today, doesn't support this feature. I think that's definitely worth supporting though! (I'm not sure it would require anything on wasm-bindgen's side of things though)

[akritrime]

But until the start situation is sorted on the compiler side, maybe the wasm-bindgen tool can treat the main function as any other exported function and re-export it in the generated wasm and then add a line to js where its executed like wasm.main() in the js code itself?

[alexcrichton]

Oh certainly! That was actually a bug in wasm-gc which I pushed/published yesterday. Wasm-bindgen internally uses wasm-gc, so updating dependencies should hopefully fix that bug!

[akritrime]

Nice. main is now exported and can be executed like any other function from a wasm module(Note: the generated JS file doesn't export it though). How about appending a line like wasm.main && wasm.main() so it checks and executes the function?

[alexcrichton]

Hm perhaps! I think I might prefer though to use the start feature of wasm and expose that through rustc, as I think that's probably the best way to model this with wasm natively

[akritrime]

Hmmm, I can understand. Using the start feature definitely feels like the right way.

[alexcrichton]

In the meantime while we're waiting for rustc to catch up though I'd be totally down for doing something like #[wasm_bindgen(start)]

[akritrime]

Sorry for the late reply, I got busy with exams and stuff. But I think the #[wasm_bindgen(start)] is a really nice idea.

[alexcrichton]

I implemented this today but I don't think it's necessarily workable. The cyclic dependency between the JS and wasm emitted means that the JS is basically unusable so you can't call imports, but that's pretty non-obvious when writing the wasm.

Until that's fixed I'd personally be a bit hesitant to land this.

[joshtriplett]

I'd love to have this available, such that the js file automatically calls the tagged main/start function as soon as it finishes loading the wasm.

[LaylBongers]

Same, writing applications entirely in Rust should preferably not need extra bootstrapping code hand-written.

[Boscop]

@LaylConway I definitely agree.
@alexcrichton
Would it then be possible to use the normal main function as start (#[wasm_bindgen(main)]), maybe even by default somehow?

[chpio]

Would it then be possible to use the normal main function as start (#[wasm_bindgen(main)]), maybe even by default somehow?

is this even possible in wasm? you can't have a "normal" main function which would normally host the main loop, but in wasm you setup things in the "main" function and return from it, returning the control to the browser/runtime-environment.

[alexcrichton]

This is definitely possible for us to do, and it largely just hasn't had anyone backing the effort needed to implement it yet!

I believe a rough implementation strategy for this would look like:

• We'll likely want to leverage the fact that rustc produces a main exported symbol for binaries
• In wasm-bindgen we can probably just either add #[wasm_bindgen(main)] or automatically hook up the main symbol to the start section. (I'd prefer the latter)
• We'll need to handle the fact that the main symbol has arguments and a return value, but the start function can have neither.

We may wish to optionally update the main symbol generation for rustc itself, using no arguments and no return value (making it suitable for a start symbol), but that may be a bit more contentious.

[chpio]

This is definitely possible for us to do, and it largely just hasn't had anyone backing the effort needed to implement it yet!

How would you do that? By using something to break out of the main fn without calling the destructors like emscripten (code)?

[alexcrichton]

@chpio that's a good point yeah, and while Rust has a different set of issues than C/C++ it's definitely true that the libstd initialization function, when it exits, performs global cleanup it assumes won't ever be necessary again.

So actually now that I think about this, I think it's not as clear that we can implement this in the standard library. In the standard library we'd have to bake in the concept of a "wasm main exiting isn't the end of the world, there's no definite end of the world!", but that's not necessarily an easy decision to make.

Instead in the meantime it may be best to simply stick with #[wasm_bindgen(main)]. That has the downside of still requiring crate-type = ["cdylib"] in Cargo.toml, but it provides a way for us to experiment with this today!