Fix some panics compiling components and resources #11798
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
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.
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Oct 6, 2025
Some stragglers from Wasmtime discovered after bytecodealliance/wasmtime#11798.
alexcrichton
added a commit
to alexcrichton/wasm-tools
that referenced
this pull request
Oct 6, 2025
Some stragglers from Wasmtime discovered after bytecodealliance/wasmtime#11798.
dicej
approved these changes
Oct 6, 2025
alexcrichton
added a commit
to alexcrichton/component-model
that referenced
this pull request
Oct 6, 2025
This commit merges tests from the wasm-tools and wasmtime repositories for the component model upstream into this repository itself. Everything should be passing in Wasmtime with `-Wexceptions` after bytecodealliance/wasmtime#11798 is merged. In terms of test suite organization AFAIK there's not precedent in the core wasm specification itself for importing tests from engines themselves. Given that I wanted to sort of chart out a new course for this which doesn't necessarily look exactly like "merge all the tests into one directory". To that end the changes here are: * New `tests/wasm-tools` and `tests/wasmtime` directories exist. * Tests are copied as-is into these folders from their upstream locations in `tests/cli/component-model` in wasm-tools and `tests/misc_testsuite/component-model` in Wasmtime. * Tests are omitted for component model features such as values and GC integration. Additionally no async tests are yet present (although some are present upstream). * Tests are kept segregated in case of a hypothetical future automatic synchronization where tests are pulled from Wasmtime directly into the spec here, for example. * Tests are not edited from their Wasmtime/wasm-tools equivalents which means they have "funky directives" at the top which are intended to only have meaning in the Wasmtime/wasm-tools repos. * In theory there could be new subdirectories such as `test/wasm-tools/async/*.wast` for proposals/extensions to the component model. I'd reorganize tests upstream for this if desired. Overall one thing I'm effectively proposing as part of this is to provide a "dumping ground" of per-repo tests which get dumped into one canonical location. The hope is that it makes it easier to contribute tests to the spec which means that the tests can rapidly grow over time. Quality of tests is intended to be enforced eventually by ensuring that at least one runtime (maybe a reference implementation) passes the tests, so not just anything could be added in theory. For now though my hope is to seed a test suite for the component model for some of the tricker cases especially related to resources as others become interested in implementing the component model.
github-merge-queue bot
pushed a commit
to bytecodealliance/wasm-tools
that referenced
this pull request
Oct 6, 2025
* More changes to upstream tests Some stragglers from Wasmtime discovered after bytecodealliance/wasmtime#11798. * Update test expectations
lukewagner
pushed a commit
to WebAssembly/component-model
that referenced
this pull request
Oct 10, 2025
This commit merges tests from the wasm-tools and wasmtime repositories for the component model upstream into this repository itself. Everything should be passing in Wasmtime with `-Wexceptions` after bytecodealliance/wasmtime#11798 is merged. In terms of test suite organization AFAIK there's not precedent in the core wasm specification itself for importing tests from engines themselves. Given that I wanted to sort of chart out a new course for this which doesn't necessarily look exactly like "merge all the tests into one directory". To that end the changes here are: * New `tests/wasm-tools` and `tests/wasmtime` directories exist. * Tests are copied as-is into these folders from their upstream locations in `tests/cli/component-model` in wasm-tools and `tests/misc_testsuite/component-model` in Wasmtime. * Tests are omitted for component model features such as values and GC integration. Additionally no async tests are yet present (although some are present upstream). * Tests are kept segregated in case of a hypothetical future automatic synchronization where tests are pulled from Wasmtime directly into the spec here, for example. * Tests are not edited from their Wasmtime/wasm-tools equivalents which means they have "funky directives" at the top which are intended to only have meaning in the Wasmtime/wasm-tools repos. * In theory there could be new subdirectories such as `test/wasm-tools/async/*.wast` for proposals/extensions to the component model. I'd reorganize tests upstream for this if desired. Overall one thing I'm effectively proposing as part of this is to provide a "dumping ground" of per-repo tests which get dumped into one canonical location. The hope is that it makes it easier to contribute tests to the spec which means that the tests can rapidly grow over time. Quality of tests is intended to be enforced eventually by ensuring that at least one runtime (maybe a reference implementation) passes the tests, so not just anything could be added in theory. For now though my hope is to seed a test suite for the component model for some of the tricker cases especially related to resources as others become interested in implementing the component model.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
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:
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.