Bake `async` into component model function types by alexcrichton · Pull Request #2376 · bytecodealliance/wasm-tools

@alexcrichton

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.

Merged via the queue into bytecodealliance:main with commit b5d95aa

Nov 14, 2025

34 checks passed

alexcrichton added a commit to dicej/wasm-tools that referenced this pull request

Nov 17, 2025

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 <joel.dice@fermyon.com>

* 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 <joel.dice@fermyon.com>

---------

Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>