|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7 |
|
| #
2ab5f547 |
| 30-Mar-2026 |
Alex Crichton <[email protected]> |
Fix a copy/paste typo in `StreamAny` (#12871)
When closing, close a stream, not a future. Fixes the test added here as well.
|
|
Revision tags: v43.0.0 |
|
| #
da093747 |
| 02-Mar-2026 |
Alex Crichton <[email protected]> |
Relax panics in async/futures to traps/errors (#12688)
* Relax panics in async/futures to traps/errors
This commit is an admittance that I don't believe we're going to get to a point where we are c
Relax panics in async/futures to traps/errors (#12688)
* Relax panics in async/futures to traps/errors
This commit is an admittance that I don't believe we're going to get to a point where we are confident enough in the fuzzing of component-model-async such that we could confidently say we're exercising the vast majority of possible panics. Development of component-model-async has shown a steady trickle of panics over the course of the development of the feature, and this trend has been persistent over time as well.
An attempt was made in #12119 to add a fuzzer dedicated to async events but that didn't actually find anything in development and it has missed a number of panics present before and discovered after its introduction. Overall I do not know how to improve the fuzzer to the point that it would find pretty much all of the existing async-related panics over time.
To help address this concern of the `concurrent.rs` implementation this commit goes through and replaces things like `unwrap()`, `assert!`, `panic!`, and `unreachable!` with an error-producing form. The benefit of this is that a bug in the implementation is less likely to result in a panic and instead just results in a non-spec-compliant trap. The downside of doing this though is that it can become unclear what errors are "first class traps", or expected to be guest reachable, and which are expected to be bugs in Wasmtime. To help address this I've performed a few refactorings here as well.
* Some traps previously present as error strings are now promoted to using `Trap::Foo` instead. This has some refactoring of the Rust/C side as well to make it easier to define new variants. Tests were additionally added for any trap messages that weren't previously tested as being reachable.
* A new `bail_bug!` macro was added (internally) for Wasmtime. This is coupled with a concrete `WasmtimeBug` error type (exported as `wasmtime::WasmtimeBug`). The intention is that `bail!` continues to be "here's a string and I'm a bit too lazy to make a concrete error" while `bail_bug!` indicates "this is a bug in wasmtime please report this if you see it".
The rough vision is that if an error condition is reached, and the system is not broken in such a way that panicking is required, then `bail_bug!` can be used to indicate a bug in Wasmtime as opposed to panicking. This reduces the real-world impact of hitting these scenarios by downgrading a CVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not all panics are able to be transitioned to this as some are load bearing from a safety perspective or similar (or indicate something equally broken), but the vast majority of cases are suitable for "return a trap, lock down the store, and let destructors take care of everything else".
This change additionally has resulted in API changes for `FutureReader` and `StreamReader`. For example creation of these types now returns a `Result` for when the `ResourceTable` is full, for example, instead of panicking.
* Fix CI build
* Translate `WasmtimeBug` to panics in debug mode
* Review comments
* Refactor some stream methods for fewer panics
show more ...
|
|
Revision tags: v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1 |
|
| #
96e19700 |
| 07-Jan-2026 |
Nick Fitzgerald <[email protected]> |
Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)
* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`
Instead of `anyhow::Error`.
This commit re-exports the `wasmtim
Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)
* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`
Instead of `anyhow::Error`.
This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error` module, updates the prelude to include these new error-handling types, redirects our top-level `wasmtime::{Error, Result}` re-exports to re-export `wasmtime::error::{Error, Result}`, and updates various use sites that were directly using `anyhow` to use the new `wasmtime` versions.
This process also required updating the component macro and wit-bindgen macro to use the new error types instead of `anyhow`.
Part of https://github.com/bytecodealliance/wasmtime/issues/12069
* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense
* cargo fmt
* Move `crate::error::Thing` to `crate::Thing` where it makes sense
show more ...
|
|
Revision tags: v40.0.0 |
|
| #
f586be11 |
| 09-Dec-2025 |
Alex Crichton <[email protected]> |
cm-async: Start to fill out `{Future,Stream}Any` (#12142)
* cm-async: Start to fill out `{Future,Stream}Any`
This commit is the first step down the road of filling out the preexisting, but empty/bu
cm-async: Start to fill out `{Future,Stream}Any` (#12142)
* cm-async: Start to fill out `{Future,Stream}Any`
This commit is the first step down the road of filling out the preexisting, but empty/buggy, `FutureAny` and `StreamAny` types. These are intended to behave similarly to `ResourceAny` where the embedder doesn't have static knowledge ahead of time about the type of the future/stream in use. Changes made here are:
* `ComponentType for {Stream,Future}Reader<T>` now correctly typecheck the `T`. * Conversion to/from `*Any` types now properly typechecks the payload type against the expected type. * `{Future,Stream}Any` now live in their own file with the matrix of conversions to the typed variants. * A `close` method was added to `*Any` types.
These types are not currently directly constructible but this will likely be relaxed in the future. Additionally the host can't actually use these values without knowing the type, which is another restriction that will be relaxed in the future (aka implemented).
cc #11161
* Fix tests
* Skip a test on miri
show more ...
|