Changes in async_dynamic.rs

2ab5f547 - Fix a copy/paste typo in `StreamAny` (#12871)

Mon, 30 Mar 2026 14:09:11 +0000

Fix a copy/paste typo in `StreamAny` (#12871)When closing, close a stream, not a future. Fixes the test added here aswell. List of files: /wasmtime-44.0.1/tests/all/component_model/async_dynamic.rs

da093747 - Relax panics in async/futures to traps/errors (#12688)

Mon, 02 Mar 2026 21:26:40 +0000

Relax panics in async/futures to traps/errors (#12688)* Relax panics in async/futures to traps/errorsThis commit is an admittance that I don't believe we're going to getto a point where we are confident enough in the fuzzing ofcomponent-model-async such that we could confidently say we'reexercising the vast majority of possible panics. Development ofcomponent-model-async has shown a steady trickle of panics over thecourse of the development of the feature, and this trend has beenpersistent over time as well.An attempt was made in #12119 to add a fuzzer dedicated to async eventsbut that didn't actually find anything in development and it has misseda number of panics present before and discovered after its introduction.Overall I do not know how to improve the fuzzer to the point that itwould find pretty much all of the existing async-related panics overtime.To help address this concern of the `concurrent.rs` implementation thiscommit goes through and replaces things like `unwrap()`, `assert!`,`panic!`, and `unreachable!` with an error-producing form. The benefitof this is that a bug in the implementation is less likely to result ina panic and instead just results in a non-spec-compliant trap. Thedownside of doing this though is that it can become unclear what errorsare "first class traps", or expected to be guest reachable, and whichare expected to be bugs in Wasmtime. To help address this I've performeda 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 systemis 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. Thisreduces the real-world impact of hitting these scenarios by downgrading aCVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not allpanics are able to be transitioned to this as some are load bearing froma safety perspective or similar (or indicate something equally broken),but the vast majority of cases are suitable for "return a trap, lockdown 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 ofpanicking.* Fix CI build* Translate `WasmtimeBug` to panics in debug mode* Review comments* Refactor some stream methods for fewer panics List of files: /wasmtime-44.0.1/tests/all/component_model/async_dynamic.rs

c09aa380 - deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

Tue, 03 Feb 2026 19:13:45 +0000

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)* deprecate `[Typed]Func::post_return[_async]` and make them no-opsWith the advent of the Component Model concurrency ABI and it's `task.return`intrinsic, post-return functions have been informally deprecated and areexpected to be removed for WASI 1.0 and the corresponding stable edition of theComponent Model. Consequently, it does not make sense anymore to requireembedders to explicitly call the post-return function after using`[Typed]Func::call[_async]`.As of this commit, `[Typed]Func::post_return[_async]` are no-ops. Instead, thepost-return function is called automatically as part of`[Typed]Func::call[_async]` if present, which is how`[Typed]Func::call_concurrent` has worked all along. In addition, this commitfixes and tests a couple of cases where the task and/or thread was beingdisposed of before the post-return function was called.* address review feedback* test post-return function in more scenariosSpecifically, I've split the `invoke_post_return` test into multiple tests:- using `TypedFunc::call`- using `TypedFunc::call_async` with concurrency support enabled- using `TypedFunc::call_async` with concurrency support disabled- using `Func::call_async` with concurrency support disabled- using `TypedFunc::call_concurrent`* remove GCC/clang-specific deprecation attributeThis broke the MSVC build.* bless bindgen output* remove obsolete post-return functions and fieldsNow that post-return calls are handled internally without requiring explicitaction by the embedder, we can avoid unnecessary bookkeeping. List of files: /wasmtime-44.0.1/tests/all/component_model/async_dynamic.rs

63679896 - Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)

Thu, 22 Jan 2026 17:56:26 +0000

Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)* Only create `ConcurrentState` in a `Store` when CM async is enabledCreating the default `ConcurrentState` will create a `FuturesUnordered` whichwill allocate. By making this state optional, we can keep making progress onhttps://github.com/bytecodealliance/wasmtime/issues/12069, and put off dealingwith `FuturesUnordered` until when we are ready to try and make CM async codehandle OOMs.* Support dynamically disabling component-model-async at runtime* fix warnings in certain cfg builds* fix another warning* Forcibly enable CM async for a couple wast tests List of files: /wasmtime-44.0.1/tests/all/component_model/async_dynamic.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/tests/all/component_model/async_dynamic.rs

f586be11 - cm-async: Start to fill out `{Future,Stream}Any` (#12142)

Tue, 09 Dec 2025 18:24:05 +0000

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 thepreexisting, but empty/buggy, `FutureAny` and `StreamAny` types. Theseare intended to behave similarly to `ResourceAny` where the embedderdoesn't have static knowledge ahead of time about the type of thefuture/stream in use. Changes made here are:* `ComponentType for {Stream,Future}Reader` 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 willlikely be relaxed in the future. Additionally the host can't actuallyuse these values without knowing the type, which is another restrictionthat will be relaxed in the future (aka implemented).cc #11161* Fix tests* Skip a test on miri List of files: /wasmtime-44.0.1/tests/all/component_model/async_dynamic.rs