Repository navigation
wasm-wave: return an error instead of panicking on unsupported values - #2778
Merged
alexcrichton merged 1 commit intoOct 21, 2026
Merged
Conversation
`Writer::write_value` panicked when it encountered a value whose kind is `WasmTypeKind::Unsupported`, which is how embedders such as Wasmtime represent component-model values that WAVE can't encode yet (e.g. `map<K, V>`, resources, streams, and futures). As a result `wasm_wave::to_string` could panic despite returning a `Result`. Add a `WriterError::UnsupportedType` variant and return it instead. `WriterError` is already `#[non_exhaustive]`, so this is not a breaking change. `DisplayValue` maps writer errors to `fmt::Error`, so formatting an unsupported value through it now returns an error as well. See bytecodealliance/wasmtime#14811.
lann
approved these changes
Oct 21, 2026
alexcrichton
approved these changes
Oct 21, 2026
jrandolf
added a commit
to jrandolf/wasmtime
that referenced
this pull request
Oct 21, 2026
WAVE can't represent some component values, such as `map`s, resources, futures, streams, and error contexts. wasm-wave's `DisplayValue` returns a `fmt::Error` for them, so formatting one panics, which made `wasmtime run --invoke` panic when the invoked function returned a `map`. `--invoke` now prints results through `Val::to_wave`, which returns an error for these values, so it reports the error and exits with a failure instead. The error messages built in `ensure_type_val` no longer format values through `DisplayValue` either. This relies on bytecodealliance/wasm-tools#2778, which makes wasm-wave's writer return an error instead of panicking on these values. It's a stopgap for bytecodealliance#14811; rendering `map`s needs support in wasm-wave.
jrandolf
added a commit
to jrandolf/wasmtime
that referenced
this pull request
Oct 21, 2026
Point the wasm-tools crates at the `wave-writer-unsupported-error` branch of jrandolf/wasm-tools, which is bytecodealliance/wasm-tools#2778 as merged but without the later changes on wasm-tools' main. Every wasm-tools crate is patched, not just wasm-wave, because within wasm-tools the crates depend on each other directly. Drop this commit once a wasm-tools release with that change is out.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Writing a value whose kind is
WasmTypeKind::Unsupportedpanicked in the writer, so e.g. Wasmtime's--invokecrashes on functions returning a component model map (bytecodealliance/wasmtime#14811). This returns a newWriterError::UnsupportedTypeinstead (WriterErroris already#[non_exhaustive]).DisplayValuestill maps it tofmt::Error, so its docs now point atto_stringfor callers that want the error.Actual map support is tracked in #2777.