Bake async into component model function types
#2376
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit is a breaking change to the component-model-async implementation in this repository. This will effectively invalidate all WASIp3 binaries created prior to this commit. Given that this feature is off-by-default everywhere (right? right?) it's expected that while this will have churn it's the appropriate time to make such a change as this. Concretely the changes here are: * Function types in the component model now reflect whether they're `async`-or-not. This is no longer WIT-level sugar. * Kebab names no longer support `[async]`, `[async method]`, or `[async static]`. * The text format now supports `(func async? (param ...))`. The binary format previously used 0x40 as the prefix byte for "this is a component function type" and now 0x43 is used as "this is an async function type". The `async_` boolean is plumbed throughout component function type locations and is required to be handled by callers. For now there is no subtyping relationship between async and non-async functions, they must be exactly the same when linking. The rationale for this change is going to be expanded on more fully in an upcoming PR to the component-model repository itself. The rough tl;dr; is that to fully support JS in/out of components the component model is going to need to require traps in some dynamic situations such as when a synchronous function-type function tries to block. This is required to respect JS's "cannot block the main thread" semantics, for example. This will be more fully explain in the component-model PR and this PR is not intended to serve as justification alone for this change. Instead this PR is intended to change/update Wasmtime as quickly as possible to understand the new binary format so implementation work can proceed as most of the work here is on the runtime side of things, not validation. One minor caveat for this change is that the `wit-dylib` crate has some tests which exercise async functionality. Those are now all disabled or set as "expect this to fail" because Wasmtime, the runner for these tests, no longer understands the binaries it's ingesting.
Member
|
@vados-cosmonic as a heads-up, this will be quite important for JCO. |
dicej
approved these changes
Nov 14, 2025
alexcrichton
added a commit
to dicej/wasm-tools
that referenced
this pull request
Nov 17, 2025
Fixing a mistake from bytecodealliance#2376
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 17, 2025
* require memory for async lifts as needed Per WebAssembly/component-model#575, both `wasm-tools` and Wasmtime have been too permissive, allowing async lifts to optionally omit a memory canonopt if only the return type (and not the parameter types) would need one. This fixes validation to require the option in such cases. Signed-off-by: Joel Dice <[email protected]> * Fix streams-and-futures test Fixing a mistake from #2376 * add memory option to lifts when needed in wit-component Signed-off-by: Joel Dice <[email protected]> --------- Signed-off-by: Joel Dice <[email protected]> Co-authored-by: Alex Crichton <[email protected]>
Contributor
|
I believe the proper link to the spec change is WebAssembly/component-model#578 (I was expecting a link from there but didn't find it) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit is a breaking change to the component-model-async implementation in this repository. This will effectively invalidate all WASIp3 binaries created prior to this commit. Given that this feature is off-by-default everywhere (right? right?) it's expected that while this will have churn it's the appropriate time to make such a change as this.
Concretely the changes here are:
async-or-not. This is no longer WIT-level sugar.[async],[async method], or[async static].(func async? (param ...)).The binary format previously used 0x40 as the prefix byte for "this is a component function type" and now 0x43 is used as "this is an async function type". The
async_boolean is plumbed throughout component function type locations and is required to be handled by callers. For now there is no subtyping relationship between async and non-async functions, they must be exactly the same when linking.The rationale for this change is going to be expanded on more fully in an upcoming PR to the component-model repository itself. The rough tl;dr; is that to fully support JS in/out of components the component model is going to need to require traps in some dynamic situations such as when a synchronous function-type function tries to block. This is required to respect JS's "cannot block the main thread" semantics, for example. This will be more fully explain in the component-model PR and this PR is not intended to serve as justification alone for this change. Instead this PR is intended to change/update Wasmtime as quickly as possible to understand the new binary format so implementation work can proceed as most of the work here is on the runtime side of things, not validation.
One minor caveat for this change is that the
wit-dylibcrate has some tests which exercise async functionality. Those are now all disabled or set as "expect this to fail" because Wasmtime, the runner for these tests, no longer understands the binaries it's ingesting.