Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async in extern "C" block is accepted but does nothing #2189

Closed
rodrigorc opened this issue Jun 5, 2020 · 4 comments
Closed

async in extern "C" block is accepted but does nothing #2189

rodrigorc opened this issue Jun 5, 2020 · 4 comments
Labels

Comments

@rodrigorc
Copy link
Contributor

Describe the Bug

In version 0.2.55, to use a JS async function in Rust I would write:

#[wasm_bindgen]
extern "C" {
    fn js_test() -> js_sys::Promise;
}
async fn js_test_() -> Result<JsValue, JsValue> {
    wasm_bindgen_futures::JsFuture::from(js_test()).await
}

Because writing async directly inside the extern "C" block was a parse error.

But now in 0.2.62 the following compiles fine:

#[wasm_bindgen]
extern "C" {
    async fn js_test() -> Result<JsValue, JsValue>;
}

Although the js_test does not return a Future, but a plain old Result. The async seems to be totally ignored.

The documentation does not mention my use case, so maybe it is not supported.

Expected Behavior

I would expect one of these, in order of preference:

  1. The JS Promise is automatically converted into a Rust Future with a hidden call to wasm_bindgen_futures::JsFuture::from(), and the return Ok type is automatically converted if different of JsValue.
  2. The compiler complaints that this usage of async is not supported, (yet?).

Actual Behavior

The code compiles but the async keyword is ignored.

@rodrigorc rodrigorc added the bug label Jun 5, 2020
@alexcrichton
Copy link
Contributor

Thanks for the report! It's definitely a bug that this doesn't work right now (or at least isn't an error). That being said I think it'd be super slick if this worked natively and returned an impl Future<...>, that'd be an awesome feature to support!

@rodrigorc
Copy link
Contributor Author

I'd be awesome indeed, and all the pieces are already there, so it should not be too complicated, I think.

I can try and implement it myself, if you are willing to do the review.

@alexcrichton
Copy link
Contributor

Sounds good to me!

@rodrigorc
Copy link
Contributor Author

Closing it, as #2196 fixes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants