Remove async func support.#307
Conversation
The `async` keyword has been removed from the [async proposal], in favor of using plain functions that with `future` or `stream` types. See also the [component-model PR to remove the syntax]. This removes the (now) old `async func` suppport from wit-bindgen, to make it easier to develop the current Canonical ABI proposal. [async proposal]: https://docs.google.com/presentation/d/1MNVOZ8hdofO3tI0szg_i-Yoy0N2QPU2C--LzVuoGSlE/edit#slide=id.g1270ef7d5b6_0_111 [component-model PR to remove the syntax]: WebAssembly/component-model#98
|
Unfortunately, the wit-bindgen demo depends on async infrastructure, so I've disabled running the demo in CI for now. |
alexcrichton
left a comment
There was a problem hiding this comment.
I agree that this is the best way forward. I think it's best to get wit-bindgen into alignment with the currently-written spec and then subsequently re-add features like async as it fits within the current iteration of the component model. Otherwise trying to adapt everything here to the new model seems onerous. I do think that a good bit of what's removed here is going to come back, but it seems so likely to come back in a different form that it's not worth preserving outside of the git history.
It might be worth leaving this open for a day or two to ensure no one else has any objections, but otherwise seems reasonable to me to merge 👍
The error I see in CI is: which I think should be easy to fix? I don't believe the demo use actual |
218a5be to
e85c962
Compare
|
Ah, ok. I've now re-enabled the demo in CI, and just removed the |
Remove async feature from host-rust crates as it no longer available. Relates bytecodealliance#307.
Remove async feature from host-rust crates as it no longer available. Relates #307.
The
asynckeyword has been removed from the async proposal, in favorof using plain functions that with
futureorstreamtypes. See alsothe component-model PR to remove the syntax.
This removes the (now) old
async funcsuppport from wit-bindgen, to makeit easier to develop the current Canonical ABI proposal.