Update WASI to 0.3.0, enable component-model-async by alexcrichton · Pull Request #13612 · bytecodealliance/wasmtime

alexcrichton · 2026-06-11T19:49:02Z

This commit updates the vendored WASI WITs for the 0.3.0 release of WASI to this repository, updating the supported version of WASI that wasmtime-wasi runs. This additionally enables the component-model-async wasm feature by default in Wasmtime, along with -Sp3 on the CLI as well. This is intended to be a comprehensive "turn WASI 0.3.0 on by default" PR which touches a few different locations.

Apart from changing version numbers some minor changes made here are:

Default enablement of the wasm cm-async feature is now conditional on Config::concurrency_support in addition to the compile-time feature. This means that if concurrency_support is disabled the default will be that cm-async is disabled.
The tests/wasi.rs test suite running the upstream wasi-testsuite repository is updated to expect failures for all WASIp3 tests due to the import versions changing. This resulted in a necessary restructuring of the test to handle a few more failures in a few more locations to ensure that "should fail tests" are correctly marked as passing when they indeed do fail.

This commit updates the vendored WASI WITs for the 0.3.0 release of WASI to this repository, updating the supported version of WASI that `wasmtime-wasi` runs. This additionally enables the `component-model-async` wasm feature by default in Wasmtime, along with `-Sp3` on the CLI as well. This is intended to be a comprehensive "turn WASI 0.3.0 on by default" PR which touches a few different locations. Apart from changing version numbers some minor changes made here are: * Default enablement of the wasm `cm-async` feature is now conditional on `Config::concurrency_support` in addition to the compile-time feature. This means that if `concurrency_support` is disabled the default will be that `cm-async` is disabled. * The `tests/wasi.rs` test suite running the upstream `wasi-testsuite` repository is updated to expect failures for all WASIp3 tests due to the import versions changing. This resulted in a necessary restructuring of the test to handle a few more failures in a few more locations to ensure that "should fail tests" are correctly marked as passing when they indeed do fail.

alexcrichton · 2026-06-11T19:49:33Z

I'll additionally clarify that my intent is to backport this to the release-46.0.0 branch upon merging to main to have Wasmtime 46.0.0 be the first with component-model-async/WASIp3 support.

github-actions · 2026-06-11T22:21:43Z

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

If you added a new Config method, you wrote extensive documentation for
it.

Details

Our documentation should be of the following form:

Short, simple summary sentence.

More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.

Is this method fallible? If so, when can it return an error?

Can this method panic? If so, when does it panic?

# Example

Optional example here.

If you added a new Config method, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.

Details

For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.

Often, all that is required of you is to ensure that there is a knob for this
configuration option in wasmtime_fuzzing::Config (or one
of its nested structs).

Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See our docs on fuzzing for more details.
If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.

Details

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

ricochet

One very minor nit, otherwise lgtm including handling exit-with-code

pchickey · 2026-06-12T01:00:03Z

@@ -1,13 +1,13 @@
-package wasi:http@0.3.0-rc-2026-03-15;
+package wasi:http@0.3.0;


This file is missing the changes from https://github.com/WebAssembly/WASI/pull/920/changes - not sure where along the chain those got missed

I see it on main: https://github.com/WebAssembly/WASI/blob/main/proposals/http/wit/worlds.wit#L35

None of the inner comments of the worlds are reflected here whether new or old.

This is a wasm-tools limitation where WorldItem::Interface doesn't have a docs field so when going from wit to binary, we loose those docs. A doc comment on the service world would persist.

Agreed yeah looks like this is a bug in wasm-tools, and thanks @ricochet for bytecodealliance/wasm-tools#2540! In the meantime the docs here don't actually get plumbed anywhere else, so this is mostly just a minor in-repo thing for us in this vendoring.

ricochet · 2026-06-12T01:14:20Z

 /// in more specific worlds such as `wasi:http/middleware`.
-@since(version = 0.3.0-rc-2026-03-15)
+@since(version = 0.3.0)
 world service {


Note none of the inner wit doc comments are reflected in the resolved wit (old or new).

This commit is intended to couple the WASI subgroup's decision today to stamp 0.3.0 and ship it. This updates the vendored WITs here to their 0.3.0 versions which means that the WASIp3 version of libc will now be built against this version. I've tested this against a build of bytecodealliance/wasmtime#13612 to verify these changes. This has a few minor changes as well such as: * The implementation of `exit` in libc now uses `exit_with_code` instead of `exit` where possible. This is only done if the `status` being exited with fits within the `u8` that the WASI interface allows. * Before cancelling/deleting the timeout task in `poll` it's removed from the `waitable-set` to accommodate upstream changes in Wasmtime and avoid a trap.

* fix: substituted_component_type panic on guest-exported resources (#13608) * add test for `substituted_component_type` panic `Linker::substituted_component_type` builds a `types::Component` whose resource substitution map is `Some(..)` but only covers the component's *imported* resources. Introspecting an exported function that references an *exported* (non-imported) resource then panics with an index-out-of-bounds, because `InstanceType::resource_type` hard-indexes that partial map (`matching.rs`) instead of falling back to treating an absent resource as uninstantiated. This adds a test that builds a component exporting a resource plus a constructor returning `own<t>` and a method taking `borrow<t>`, then walks the introspected function types via `substituted_component_type`. It panics today (index out of bounds) and will pass once the resolver falls back gracefully. Assisted-by: claude:claude-opus-4-8 * fix panic on guest-exported resources `Linker::substituted_component_type` constructs the introspection type with `resources: Some(&cx.imported_resources)`, a map that only contains the component's *imported* resources. `InstanceType::resource_type` previously hard-indexed that map (`self.resources.map(|t| t[ty])`), so resolving a resource that is not in the map -- e.g. a resource the component *exports* -- panicked with an index-out-of-bounds whenever an exported function's params/results referenced it. Fix this by using a fallible lookup and falling back to `ResourceType::uninstantiated` when the resource is absent from the map, exactly as the `resources: None` path already does. This is the semantically correct behavior: a resource that has no substitution is "not (yet) instantiated", which is also what `Component::component_type()` relies on (it passes `resources: None`). With this fix the same safe, public introspection API no longer panics depending on which (also public) API produced the `types::Component`. Assisted-by: claude:claude-opus-4-8 * Relax version requirement on `cc` (#13617) Integration upstream into rust-lang/rust will be a bit easier with this relaxed bound, so widen the version requirement here a bit. * Run `cargo fetch` in a retry loop on CI (#13624) The number of failures right now is... high. Bake a `cargo fetch` directly into all Rust installations on CI and put a loop around it. * Try to make DNS tests more robust (#13619) Throw out timeouts and try to handle them more aggressively to see if this can reduce the number of flaky failures we see in CI... * Update WASI to 0.3.0, enable component-model-async (#13612) * Update WASI to 0.3.0, enable component-model-async This commit updates the vendored WASI WITs for the 0.3.0 release of WASI to this repository, updating the supported version of WASI that `wasmtime-wasi` runs. This additionally enables the `component-model-async` wasm feature by default in Wasmtime, along with `-Sp3` on the CLI as well. This is intended to be a comprehensive "turn WASI 0.3.0 on by default" PR which touches a few different locations. Apart from changing version numbers some minor changes made here are: * Default enablement of the wasm `cm-async` feature is now conditional on `Config::concurrency_support` in addition to the compile-time feature. This means that if `concurrency_support` is disabled the default will be that `cm-async` is disabled. * The `tests/wasi.rs` test suite running the upstream `wasi-testsuite` repository is updated to expect failures for all WASIp3 tests due to the import versions changing. This resulted in a necessary restructuring of the test to handle a few more failures in a few more locations to ensure that "should fail tests" are correctly marked as passing when they indeed do fail. * Fix handling an erroneous exit * Review comments * Add release notes * fix(cranelift): pulley clobber slot collision (#13621) * pulley: add regression test for clobber-save slot collision A `preserve_all` frame on pulley can save both manually-managed clobbers (x0-x15, floats, vectors) and pulley-managed clobbers (x16+, saved at the top of the frame by `push_frame_save`). When both are present, a manually-managed register could be assigned the same stack slot that `push_frame_save` already uses for a pulley-managed register, so the two stores collide and corrupt the saved value. Add a `preserve-all.clif` case (pulley32 and pulley64) whose frame holds a value live across a call in a pulley-managed callee-saved register (x16) while the calls clobber x0-x15. The committed precise output is the correct layout (x0 saved below the pulley-saved region); without the layout fix the emitted code stores both x16 and x0 to the same offset. * pulley: fix clobber-save stack-slot collision `FrameLayout::manually_managed_clobbers` walked `clobbered_callee_saves` from the top of the frame assuming the pulley-managed registers (saved by `push_frame_save`) come first. They do not: `clobbered_callee_saves` is sorted by register, and the manually-managed integer registers x0-x15 sort before the pulley-managed x16-x31. As a result the first manually-managed register was assigned the topmost slot, which `push_frame_save` already uses for the first pulley-saved register, so the two stores collided and the pulley-saved register was restored from a clobbered slot. Reserve the top `num_saved_by_pulley` 8-byte slots for the pulley-managed registers (matching `push_frame_save`) and hand the lower slots to the manually-managed registers, eliminating the overlap. * Add a retry loop around docker image building (#13625) Because apparently we need retry loops on everything now --------- Co-authored-by: Roman Volosatovs <rvolosatovs@users.noreply.github.com>

alexcrichton requested review from a team as code owners June 11, 2026 19:49

alexcrichton requested review from fitzgen and pchickey and removed request for a team June 11, 2026 19:49

Fix handling an erroneous exit

1231937

github-actions Bot added wasi Issues pertaining to WASI wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:config Issues related to the configuration of Wasmtime labels Jun 11, 2026

alexcrichton mentioned this pull request Jun 11, 2026

Update WASIp3 WITs to 0.3.0 WebAssembly/wasi-libc#798

Merged

ricochet reviewed Jun 11, 2026

View reviewed changes

Comment thread src/common.rs Outdated

pchickey reviewed Jun 12, 2026

View reviewed changes

ricochet reviewed Jun 12, 2026

View reviewed changes

Review comments

4df3edb

ricochet mentioned this pull request Jun 12, 2026

wasi 0.3.0 bytecodealliance/jco#1627

Merged

pchickey approved these changes Jun 12, 2026

View reviewed changes

alexcrichton added this pull request to the merge queue Jun 12, 2026

Merged via the queue into bytecodealliance:main with commit 546c294 Jun 12, 2026
51 checks passed

alexcrichton deleted the wasip3 branch June 12, 2026 18:51

alexcrichton mentioned this pull request Jun 12, 2026

[46.0.0] Some more backports #13626

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update WASI to 0.3.0, enable component-model-async#13612

Update WASI to 0.3.0, enable component-model-async#13612
alexcrichton merged 3 commits into
bytecodealliance:mainfrom
alexcrichton:wasip3

alexcrichton commented Jun 11, 2026

Uh oh!

alexcrichton commented Jun 11, 2026

Uh oh!

github-actions Bot commented Jun 11, 2026

Uh oh!

ricochet left a comment

Uh oh!

Uh oh!

pchickey Jun 12, 2026

Uh oh!

ricochet Jun 12, 2026

Uh oh!

ricochet Jun 12, 2026

Uh oh!

alexcrichton Jun 12, 2026

Uh oh!

ricochet Jun 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -1,13 +1,13 @@
		package wasi:http@0.3.0-rc-2026-03-15;
		package wasi:http@0.3.0;

Conversation

alexcrichton commented Jun 11, 2026

Uh oh!

alexcrichton commented Jun 11, 2026

Uh oh!

github-actions Bot commented Jun 11, 2026

Label Messager: wasmtime:config

Uh oh!

ricochet left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pchickey Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

ricochet Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

ricochet Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

alexcrichton Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

ricochet Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants