Skip to content

[46.0.0] Some more backports#13626

Open
alexcrichton wants to merge 8 commits into
bytecodealliance:release-46.0.0from
alexcrichton:backports
Open

[46.0.0] Some more backports#13626
alexcrichton wants to merge 8 commits into
bytecodealliance:release-46.0.0from
alexcrichton:backports

Conversation

rvolosatovs and others added 6 commits June 12, 2026 11:53
…tecodealliance#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
Integration upstream into rust-lang/rust will be a bit easier with this
relaxed bound, so widen the version requirement here a bit.
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.
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...
…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
@alexcrichton alexcrichton requested review from a team as code owners June 12, 2026 18:59
@alexcrichton alexcrichton requested review from fitzgen and pchickey and removed request for a team June 12, 2026 18:59
rvolosatovs and others added 2 commits June 12, 2026 12:36
* 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.
Because apparently we need retry loops on everything now
@alexcrichton alexcrichton requested a review from a team as a code owner June 12, 2026 19:36
@github-actions github-actions Bot added cranelift Issues related to the Cranelift code generator wasi Issues pertaining to WASI wasmtime:docs Issues related to Wasmtime's documentation labels Jun 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cranelift Issues related to the Cranelift code generator wasi Issues pertaining to WASI wasmtime:docs Issues related to Wasmtime's documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants