`async main()` support

[daxpedda]

Motivation

I think it would be great to support something like this:

#[wasm_bindgen(start)]
async fn main() { }

It would add a bit of quality-of-life to prevent users from having to use weird workarounds. It would also help a bit with cross-platform codebases.

Proposed Solution

The solution is probably the same as the ones used by tokio::main and async_std::main, they usually remove the async keyword and insert their code inside the function. I believe the only current limitation of #[wasm_bindgen(start)] is that it doesn't remove the async keyword.

Alternatives

• Stick with what we have now, which works quiet fine.
• Introduce a separate attribute? E.g.: #[wasm_bindgen(start_async)].

Additional Context

Original issue: https://github.com/rustwasm/wasm-bindgen/issues/1904 PR: https://github.com/rustwasm/wasm-bindgen/pull/1905

I'm happy to do a PR, but wanted to ask if this feature is desired first. Also some pointers would be great, I briefly looked into it and the architecture around proc-macro handling in wasm-bindgen is quite big.

[ranile]

Is it currently not supported? It seems like #1905 added that

[daxpedda]

The issue arises when you are trying to use it in binary targets or for Cargo examples. A main function is mandatory there and the compiler will complain that main doesn't support async.

#1905 added support to have a function be async with #[wasm_bindgen(start)].

This is supported:

#[wasm_bindgen(start)]
pub async fn main_js() {
    // insert your code here
}

fn main() { }

This isn't:

#[wasm_bindgen(start)]
async fn main() {
    // insert your code here
}

[ranile]

Oh, that makes sense.

Checking if the function name is main and it returns () (only type that spawn_local supports) and removing the async keyword sounds good to me.