Home Original page

Prepare some component-model tests for upstreaming by alexcrichton · Pull Request #2335 · bytecodealliance/wasm-tools

@alexcrichton 

This commit prepares a number of the `component-model/*.wast` tests for
upstreaming into the component model repository itself. Namely:

* All `value`-related functionality is moved to `values.wast` instead of
  being spread out.
* All components are now either `component definition` or a nested
  component to work well in Wasmtime (previously everything assumed it
  could import anything).

Tests now pass with `wasmtime wast` and after this I plan on upstreaming
these tests to the component model repository itself.

Merged via the queue into bytecodealliance:main with commit 1c17a18

Oct 6, 2025

34 checks passed

@alexcrichton alexcrichton deleted the refactor-component-model-tests-to-upstream branch

October 6, 2025 20:02

alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request

Oct 6, 2025 
In working on bytecodealliance/wasm-tools#2335 I found that there's a
few test cases in wasm-tools which Wasmtime was panicking to compile.
The issues were all related to resource types and how information wasn't
registered ahead of time before it was translated from wasmparser's
representation to Wasmtime's representation. The high-level cause for
this had to do with how component and instance types are handled, as
opposed to concrete components or instances themselves. This was
effectively a hole in Wasmtime's translation process for components
which has never been filled out since the original implementation of
resources. The reason that this never came up before is:

* Most components don't currently import or export a component itself.
* Most components don't currently import or export component or instance
  types (as opposed to values).

One of these was required to trigger this issue. The solution
implemented in this commit is to plumb the concept of an "abstract
resource" which is part of a type but not actually ever used at runtime
except for type equality during type reflection. This is expected to
have little-to-no impact on real-world components given that these
situations are rarely occurring.

github-merge-queue bot pushed a commit to bytecodealliance/wasmtime that referenced this pull request

Oct 6, 2025 
In working on bytecodealliance/wasm-tools#2335 I found that there's a
few test cases in wasm-tools which Wasmtime was panicking to compile.
The issues were all related to resource types and how information wasn't
registered ahead of time before it was translated from wasmparser's
representation to Wasmtime's representation. The high-level cause for
this had to do with how component and instance types are handled, as
opposed to concrete components or instances themselves. This was
effectively a hole in Wasmtime's translation process for components
which has never been filled out since the original implementation of
resources. The reason that this never came up before is:

* Most components don't currently import or export a component itself.
* Most components don't currently import or export component or instance
  types (as opposed to values).

One of these was required to trigger this issue. The solution
implemented in this commit is to plumb the concept of an "abstract
resource" which is part of a type but not actually ever used at runtime
except for type equality during type reflection. This is expected to
have little-to-no impact on real-world components given that these
situations are rarely occurring.

bongjunj pushed a commit to prosyslab/wasmtime that referenced this pull request

Oct 20, 2025 
…11798)

In working on bytecodealliance/wasm-tools#2335 I found that there's a
few test cases in wasm-tools which Wasmtime was panicking to compile.
The issues were all related to resource types and how information wasn't
registered ahead of time before it was translated from wasmparser's
representation to Wasmtime's representation. The high-level cause for
this had to do with how component and instance types are handled, as
opposed to concrete components or instances themselves. This was
effectively a hole in Wasmtime's translation process for components
which has never been filled out since the original implementation of
resources. The reason that this never came up before is:

* Most components don't currently import or export a component itself.
* Most components don't currently import or export component or instance
  types (as opposed to values).

One of these was required to trigger this issue. The solution
implemented in this commit is to plumb the concept of an "abstract
resource" which is part of a type but not actually ever used at runtime
except for type equality during type reflection. This is expected to
have little-to-no impact on real-world components given that these
situations are rarely occurring.