Changes in flags_concurrent.rs

1e0b0b46 - Remove subtask reparenting (#12570)

Mon, 23 Feb 2026 21:00:21 +0000

Remove subtask reparenting (#12570)This commit updates the implementation of component-model-asyncprimitives to remove the manual subtask reparenting process. This isrequired to fix #12544 at a semantic level because a subtask isn't everactually reparented, even if its parent exits. The first part of thischange is to remove the `GuestTask::subtasks` field and all relevantmanipulations of it.This field, however, powered the `TaskExit` abstraction returned from`call_concurrent`. This commit then subsequently deletes `TaskExit` andall related infrastructure as it's no longer directly applicable as-is.The rest of this change is then updating tests/bindings/etc to accountfor these two changes.The main semantic changes related to tests are:* `wasmtime run`, with and without `--invoke`, no longer waits for all subtasks. This instead only waits for the main task returning before exiting. Whether or not this is the correct behavior is under discussion in WebAssembly/component-model#608* `wasmtime serve` has been updated to keep the store alive at least until the response body has been fully transmitted. This is also part of WebAssembly/component-model#608.* Some `component-async-tests`-related tests were updated to either avoid blocking the store as it wasn't needed or yield enough times to ensure that the test passes.Closes #12544prtest:full List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

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, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse 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 List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

fee9be21 - Add a new fuzzer focused on component-model-async events (#12119)

Tue, 09 Dec 2025 19:32:20 +0000

Add a new fuzzer focused on component-model-async events (#12119)* Add a new fuzzer focused on component-model-async eventsThis commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtimewhich is focused on async events and interleavings of components usingthe component-model-async proposal. This fuzzer works by having aprecompiled guest program which serves as the component to run. Thisprecompiled component has a custom `fuzz.wit` which is used to interfacewith the fuzzer itself. The fuzzer is then a fuzz-generated sequence ofcommands to send to the component which verifies that everythingexecutes correctly, has no panics, etc.This fuzzer intends to stress async communication and taskinfrastructure with component-model-async. Notably this does not stresslifting/lowering or arbitrary type signatures. This does, however,permute all of the following:* Guest/host interactions (also guest/guest, host/host, etc).* Async functions, both ready and pending.* Future operations: reads, writes, cancellation, transfers, etc.* Stream operations: reads, writes, cancellation, transfers, etc.This is all throwing into a large "soup" and then asserted to workcorrectly. There's a few gotchas here and there for how this fuzzer isdesigned, such as some events requiring "yield N times to await thisevent happening". This is required because Wasmtime is allowed tonon-deterministically select between a number of "ready events" and whatto dispatch.This is not intended to be a one-size-fits-all fuzzer forcomponent-model-async. The recent enhancements to the `component_api`fuzzer are intended to complement this fuzzer in terms of what'sstressed where internally.* Review comments List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

080faa1a - add `task_exit` option to `wasmtime-wit-bindgen` (#11665)

Wed, 10 Sep 2025 20:27:13 +0000

add `task_exit` option to `wasmtime-wit-bindgen` (#11665)This builds on #11662 by optionally exposing the `TaskExit` return value from`[Typed]Func::call_concurrent` in the bindings generated for exported functions.Note that the first two commits are shared with #11662.Fixes #11600Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

f75ae788 - return `TaskExit` future from `[Typed]Func::call_concurrent` (#11662)

Wed, 10 Sep 2025 16:37:25 +0000

return `TaskExit` future from `[Typed]Func::call_concurrent` (#11662)* return `TaskExit` future from `[Typed]Func::call_concurrent`In addition to returning the value produced by the callee, these functions nowalso return a `TaskExit` future which resolves once the subtask (and anytransitively-created subtasks) have exited. This partially addresses #11600;the next step will be to add a `wasmtime-wit-bindgen` option to expose the`TaskExit` value in generated bindings.Signed-off-by: Joel Dice * address review feedback`TaskExit` now has an `async fn block` instead of closing over an `implAsAccessor` and implementing `Future`.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

9f47be2e - Support store-access in `bindgen!` generated imports (#11628)

Fri, 05 Sep 2025 21:28:49 +0000

Support store-access in `bindgen!` generated imports (#11628)* Support store-access in `bindgen!` generated importsThis commit adds support to accessing the store in `bindgen!`-generatedimport functions in traits. Since the inception of `bindgen!` this hasnever been possible and access to the store requires manually workingwith `Linker`, for example. This is not easy to do because it requiressurgically editing code or working around what bindings generation partsyou do want.The implementation here is a small step away from whatcomponent-model-async has already implemented for async functions.Effectively it's a small extension of the `*WithStore` traits to alsohave synchronous functions with `Access` parameters instead of `async`functions with an `Accessor` parameter.This is something we're going to want for the WASIp3 implementationwhere I've noticed some resource destructors are going to want access tothe store to close out streams and such and this'll provide the bindingsnecessary for that.Closes #11590* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

5764da5f - Revamp component model stream/future host API (again) (#11515)

Thu, 04 Sep 2025 21:12:18 +0000

Revamp component model stream/future host API (again) (#11515)* Revamp component model stream/future host API (again)This changes the host APIs for dealing with futures and streams from a"rendezvous"-style API to a callback-oriented one.Previously you would create e.g. a `StreamReader`/`StreamWriter` pair and calltheir `read` and `write` methods, respectively, and those methods would return`Future`s that resolved when the operation was matched with a corresponding`write` or `read` operation on the other end.With the new API, you instead provide a `StreamProducer` trait implementationwhe creating the stream, whose `produce` method will be called as soon as a readhappens, giving the implementation a chance to respond immediately withoutmaking the reader wait for a rendezvous. Likewise, you can match the read endof a stream to a `StreamConsumer` to respond immediately to writes. This modelshould reduce scheduling overhead and make it easier to e.g. pipe items to/from`AsyncWrite`/`AsyncRead` or `Sink`/`Stream` implementations without needing toexplicitly spawn background tasks. In addition, the new API provides directaccess to guest read and write buffers for `stream` operations, enablingzero-copy operations.Other changes:- I've removed the `HostTaskOutput`; we were using it to run extra code with access to the store after a host task completes, but we can do that more elegantly inside the future using `tls::get`. This also allowed me to simplify `Instance::poll_until` a bit.- I've removed the `watch_{reader,writer}` functionality; it's not needed now given that the runtime will automatically dispose of the producer or consumer when the other end of the stream or future is closed -- no need for embedder code to manage that.- In order to make `UntypedWriteBuffer` `Send`, I had to wrap its raw pointer `buf` field in a `SendSyncPtr`.- I've removed `{Future,Stream}Writer` entirely and moved `Instance::{future,stream}` to `{Future,Stream}Reader::new`, respectively.- I've added a bounds check to the beginnings of `Instance::guest_read` and `Instance::guest_write` so that we need not do it later in `Guest{Source,Destination}::remaining`, meaning those functions can be infallible.Note that I haven't updated `wasmtime-wasi` yet to match; that will happen inone or more follow-up commits.Signed-off-by: Joel Dice * Add `Accessor::getter`, rename `with_data` to `with_getter`* fixup bindgen invocationSigned-off-by: Roman Volosatovs * add support for zero-length writes/reads to/from hostI've added a test to cover this; it also tests direct buffer access for`stream`, which I realized I forgot to cover earlier. And of course therewas a bug :facepalm:.Signed-off-by: Joel Dice * add `{Destination,Source}::remaining` methodsThis can help `Stream{Producer,Consumer}` implementations determine how manyitems to write or read, respectively.Signed-off-by: Joel Dice * wasi: migrate sockets to new APISigned-off-by: Roman Volosatovs * tests: read the socket stream until EOFSigned-off-by: Roman Volosatovs * p3-sockets: account for cancellationSigned-off-by: Roman Volosatovs * p3-sockets: mostly ensure byte buffer cancellation-safetySigned-off-by: Roman Volosatovs * p3-filesystem: switch to new APISigned-off-by: Roman Volosatovs * fixup! p3-sockets: mostly ensure byte buffer cancellation-safety* p3-cli: switch to new APISigned-off-by: Roman Volosatovs * p3: limit maximum buffer sizeSigned-off-by: Roman Volosatovs * p3-sockets: remove reuseaddr test loop workaroundSigned-off-by: Roman Volosatovs * p3: drive I/O in `when_ready`Signed-off-by: Roman Volosatovs * fixup! p3: drive I/O in `when_ready`* Refine `Stream{Producer,Consumer}` APIsPer conversations last week with Roman, Alex, and Lann, I've updated thesetraits to present a lower-level API based on `poll_{consume,produce}` functionsand have documented the implementation requirements for various scenarios whichhave come up in `wasmtime-wasi`, particularly around graceful cancellation. Seethe doc comments for those functions for details.Signed-off-by: Joel Dice * being integration of new APISigned-off-by: Roman Volosatovs * update wasi/src/p3/filesystem to use new stream APIThis is totally untested so far; I'll run the tests once we have everything elsecompiling.Signed-off-by: Joel Dice * update wasi/src/p3/cli to use new stream APIThis is totally untested and doesn't even compile yet due to a lifetime issue Idon't have time to address yet. I'll follow up later with a fix.Signed-off-by: Joel Dice * fix: remove `'a` bound on `&self`Signed-off-by: Roman Volosatovs * finish `wasi:sockets` adaptationSigned-off-by: Roman Volosatovs * finish `wasi:cli` adaptationNote, that this removes the read optimization - let's get theimplementation complete first and optimize laterSigned-off-by: Roman Volosatovs * remove redundant loop in socketsSigned-off-by: Roman Volosatovs * wasi: buffer on 0-length readsSigned-off-by: Roman Volosatovs * finish `wasi:filesystem` adaptationSigned-off-by: Roman Volosatovs * remove `MAX_BUFFER_CAPACITY`Signed-off-by: Roman Volosatovs * refactor `Cursor` usageSigned-off-by: Roman Volosatovs * impl Default for VecBufferSigned-off-by: Roman Volosatovs * refactor: use consistent import stylingSigned-off-by: Roman Volosatovs * feature-gate fs Arc accessorsSigned-off-by: Roman Volosatovs * Update test expectations---------Signed-off-by: Joel Dice Signed-off-by: Roman Volosatovs Co-authored-by: Alex Crichton Co-authored-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

1155d6df - Redesign function configuration in `bindgen!` (#11328)

Mon, 28 Jul 2025 18:31:06 +0000

Redesign function configuration in `bindgen!` (#11328)* Redesign function configuration in `bindgen!`This commit is a redesign of how function-level configuration works inWasmtime's `bindgen!` macro. The main goal of this redesign is tobetter support WASIp3 and component model async functions. Prior to thisredesign there was a mish mash of mechanisms to configure behavior ofimports/exports:* The `async` configuration could turn everything async, nothing async, only some imports async, or everything except some imports async.* The `concurrent_{imports,exports}` keys were required to explicitly opt-in to component model async signatures and applied to all imports/exports.* The `trappable_imports` configuration would indicate a list of imports allowed to trap and it had special configuration for everything, nothing, and only a certain list.* The `tracing` and `verbose_tracing` keys could be applied to either nothing or all functions.Overall the previous state of configuration in `bindgen!` was clearly ahodgepodge of systems that organically grew over time. In my personalopinion it was in dire need of a refresh to take into account howcomponent-model-async ended up being implemented as well asconsolidating the one-off systems amongst all of these configurationkeys. A major motivation of this redesign, for example, was to inheritbehavior from WIT files by default. An `async` function in WIT shouldnot require `concurrent_*` keys to be configured, but rather it shouldgenerate correct bindings by default.In this commit, all of the above keys were removed. All keys have beenreplaced with `imports` and `exports` configuration keys. Each behavesthe same way and looks like so: bindgen!({ // ... imports: { // enable tracing for just this function "my:local/interface/func": tracing, // enable verbose tracing for just this function "my:local/interface/other-func": tracing | verbose_tracing, // this is blocking in WIT, but generate async bindings for // it "my:local/interface/[method]io.block": async, // like above, but use "concurrent" bindings which have // access to the store. "my:local/interface/[method]io.block-again": async | store, // everything else is, by default, trappable default: trappable, }, });Effectively all the function-level configuration items are now bitflags.These bitflags are by default inherited from the WIT files itself (e.g.`async` functions are `async | store` by default). Further configurationis then layered on top at the desires of the embedder. Supported keys are:* `async` - this means that a Rust-level `async` function should be generated. This is either `CallStyle::Async` or `CallStyle::Concurrent` as it was prior, depending on ...* `store` - this means that the generated function will have access to the store on the host. This is only implemented right now for `async | store` functions which map to `CallStyle::Concurrent`. In the future I'd like to support just-`store` functions which means that you could define a synchronous function with access to the store in addition to an asynchronous function.* `trappable` - this means that the function returns a `wasmtime::Result`. If `trappable_errors` is applicable then it means just a `Result` is returned (like before)* `tracing` - this enables `tracing!` integration for this function.* `verbose_tracing` - this logs all argument values for this function (including lists).* `ignore_wit` - this ignores the WIT-level defaults of the function (e.g. ignoring WIT `async`).The way this then works is all modeled is that for any WIT functionbeing generated there are a set of flags associated with that function.To calculate the flags the algorithm looks like:1. Find the first matching rule in the `imports` or `exports` map depending on if the function is imported or exported. If there is no matching rule then use the `default` rule if present. This is the initial set of flags for the function (or empty if nothing was found).2. If `ignore_wit` is present, return the flags from step 1. Otherwise add in `async | store` if the function is `async` in WIT.The resulting set of flags are then used to control how everything isgenerated. For example the same split traits of today are stillgenerated and it's controlled based on the flags. Note though that theprevious `HostConcurrent` trait was renamed to `HostWithStore` to makespace for synchronous functions in this trait in the future too.The end result of all these changes is that configuring imports/exportsnow uses the exact same selection system as the `with` replacement map,meaning there's only one system of selecting functions instead of 3.WIT-level `async` is now respected by default meaning that bindings workby default without further need to configure anything (unless morefunctionality is desired).One final minor change made here as well is that auto-generated`instantiate` methods are now always synchronous and an`instantiate_async` method is unconditionally generated for async mode.This means that bindings always generate both functions and it's up tothe embedder to choose the appropriate one.Closes #11246Closes #11247* Update expanded test expectationsprtest:full* Fix the min platform embedding example* Fix doc tests* Always generate `*WithStore` traitsThis helps when using the `with` mapping since that can always assumethat `HostWithStore` is available in the generated bindings, avoidingthe need to duplicate configuration options.* Update test expectations* Review comments List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

64bc3bd9 - Start to use `&Accessor` more in concurrent code (#11238)

Tue, 15 Jul 2025 15:14:02 +0000

Start to use `&Accessor` more in concurrent code (#11238)* Start to use `&Accessor` more in concurrent codeAfter discussion with Joel we've concluded that while `&mut Accessor`was originally added to model host functions it is also appropriate touse it to model embedder-rooted invocations of items such as wasm aswell. Effectively the conclusion we reached was that`*::call_concurrent` should be taking `&Accessor`, not`StoreContextMut`. This has a number of benefits to it over the previousiteration:* This makes exports behave more like imports where `Accessor` means "you're in the concurrent world".* This makes exports have an `async fn` signature which is easier to read and understand.* This automatically enforces the guarantee that the returned future is only polled within the main event loop because the future is always considered to close over the `&Accessor` provided meaning it statically cannot live outside of the event loop.* This paves the way forward to future refactorings to avoid storing so much state within a `Store` and instead try to store state directly in futures themselves. This should make cancellation more natural and eventually also remove `'static` bounds on params/results. Furthermore this should make it easier to avoid spawning tasks internally by storing state in futures instead of spawned tasks.In doing this one of the main questions we were faced with was what todo about `&mut Accessor`, namely the `mut` part. With a mutableaccessor it would be only possible to call one function concurrently.One option considered was to add combinators like `Accessor::join` and`Accessor::race` but in the end we decided to avoid going that directionand instead switch to `&Accessor` everywhere, freely enablingaliasing of the accessor. This has the downside that `Accessor::with` isnow a relatively dangerous function in that it can panic, but idiomaticusage of it is not expected to panic as the distinction between the`async` and sync boundary of `Accessor` vs `StoreContextMut` is expectedto naturally make the recursive panic condition of `with` rare to comeup in practice.Concrete changes in this commit are:* `Accessor::with` now requires `&self`.* `Accessor::spawn` now requires `&self`.* Host functions are now given `&Accessor`, not `&mut Accessor`.* `{Typed,}Func::call_concurrent` is now an `async fn` which takes an `&Accessor` instead of `StoreContextMut`.* Guest bindings generation for concurrent invocations now looks exactly like async bindings generation except for replacing `StoreContextMut` with `Accessor`.Note that this commit does not yet update the internal implementationsof these functions to benefit from the new abilities that taking`&Accessor` implies. Instead that's deferred to a future update asnecessary. Instead this is only updating the public API of the`wasmtime` crate to enable these refactorings in the future.Also note that this does not yet update all functions to take`&Accessor`. Notably futures and streams still need to be updated.cc #11224* Review comments---------Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

b221fca7 - update `component-model-async` plumbing (#11123)

Thu, 03 Jul 2025 22:03:59 +0000

update `component-model-async` plumbing (#11123)* [DO NOT MERGE] update `component-model-async` plumbingThis pulls in the latest Component Model async ABI code from the`wasip3-prototyping` repo, including various API refactors and spec updates.This includes all the changes to the `wasmtime` crate from `wasip3-prototyping`_except_ that the `concurrent` submodule and child submodules contain onlynon-functional stubs. For that reason, and the fact thate.g. `Func::call_async` is now implemented in terms of `Func::call_concurrent`,most of the component model tests are failing. This commit is not meant to bemerged as-is; a follow-up commit (to be PR'd separately) will contain the real`concurrent` implementation, at which point the tests will pass again. I'msplitting these into separate PRs to make review easier.Signed-off-by: Joel Dice * Undo wit-bindgen changesNo longer necessary after other refactors* Move back to crates.io-based wit-bindgen* Undo upgrade of http-body-util(deferred for future PR)* Add back in arbitrary use of asyncLooks like it may have been lost by accident* Make imports more conventional for Wasmtime* Some minor changes* Privatize a component field* Cut down a bit on #[cfg]* Undo a no-longer-necessary `pub`* add doc comments for `{Future,Stream,ErrorContext}Any`Signed-off-by: Joel Dice * rename `concurrent` stub module to `concurrent_disabled`...and avoid panicking in the stubs.Signed-off-by: Joel Dice * fix test regressionSigned-off-by: Joel Dice * revert `call_async` and `post_return_impl` changesThese will need to wait until the `component-model-async` feature is fullyimplemented.Signed-off-by: Joel Dice * remove unused structSigned-off-by: Joel Dice * add `Options::callback` fieldThis isn't used yet, but will be used when the real `component-model-async`implementation is merged.Signed-off-by: Joel Dice * Remove no-longer-needed feature* Trim reexports from WasmtimeSome of these are no longer needed or can be avoided with small changes.Some deps are likely needed in the next commit but they'll be best addedthere.* Update test expectations* More trimming of Cargo.toml* Defer `*Buffer` traits to next PRNot needed for this PR I believe.* Use conventional Wasmtime imports + remove dummy_waker* Reduce duplication in `*_disabled`* Remove some unncessary bounds* Remove some `for<'a>` bounds where unnecessary* Remove another bound* Defer more functions to the next PR`drop_fibers` is different in the next PR, so defer it to then.* Remove some reexports no longer necessaryBindings generation changed awhile back so these aren't needed, deferthe implementations to the next PR.* Remove unnecessary dropThis was already moved to `run_manual_drop_routines`* Defer a `pub(crate)` to a future PR* Expand comments in traphandlers* Defer some types to the next PR* Update linker documentation* Add `Send`/`Sync` bounds to `ComponentType`This commit is extracted from from review of #11123 and #11127. Whilenot literally present in those PRs it's my own personal conclusion thatit's best to just go ahead and add these bounds at the "base" of thecomponent trait hierarchy. The current implementation in #11123 addsbounds in many locations and this would remove the need to add boundseverywhere and instead have everything inherited through the `Lift` and`Lower` traits.This raises the question of: why? The main conclusion that I've reachedleading to this change is that Wasmtime currently will store `R`, areturn value, on the stack during the lowering process back into linearmemory. This might involve allocation, however, meaning that wasm can beinvoked and a context switch could happen. For Wasmtime's `unsafe impl`of `Send` and `Sync` on fibers to be sound it requires that thisstack-local variable is also `Send` and `Sync` as it's an entirelyuser-provided type. Thus I've concluded that for results it's alwaysrequired for these to be both `Send` and `Sync` (or at the very least,`Send`).Given that I've gone ahead and updated to require both `Send` and `Sync`for both params and results. This is not expected to actually have anyimpact in practice since all primitives are already `Send`/`Sync` (minus`Rc` impls all removed here) and all `bindgen!`-generated types arecompositions of `Send`/`Sync` primitives meaning that they're also`Send` and `Sync`.* Remove some now-unnecessary bounds* Fix build after #11160* Remove some now-unnecessary duplicate bounds* Uncomment test that now works* Undo accidental doc wrap* Clarify comment on `Value` typesDon't leave `TODO` in public-facing documentation ideally* Actually resolve the conflict (forgot to commit)* Avoid returning boxed futures in APIs* Defer making constructors more public to a future PR* Make a method name more conventional* Refactor `linear_lift_into_from_memory`* Drop the `max_count` parameter in favor of slicing the `WasmList` itself. Avoids situations such as what happens if `max_count` is larger than the length of the list.* Don't have the default implementation collect to a vector and then push all that onto a different vector. Instead push each item individually through `extend`.* De-indent a block of code added* Remove unsafety from `prepare_call`Mostly move the parameters themselves to the closure to avoid rawpointers/drop/etc.This will have the consequence of in the future `call_async` is going tonow require `Params: 'static` but that seems more-or-less inevitable atthis point.* Go back to returning box, alas.* Apply same treatment to lift functionMake it a closure and reduce some levels of indirection of the variousfunctions in play.* Refactor `lower_params` to require less context.Relax the bounds on the closure specified since it's immediately calledand then additionally take out parameters/captures that the closure cancarry itself.* Don't pass extraneous `Instance` parameterThis can now be inferred from `Func`.* Clean up some SAFETY comments* Generalize the signature of `lift_results`* Move `lift_results` function to `Func`Also rename the lift/lower helpers to `with_{lift,lower}_context`* Remove parameter from `with_lift_context`Like `with_lower_context` this is fine to capture in the closure passedin.* Simplify the dynamic lifting logicDon't call `with_lift_context` in two locations, only call it once witha dynamic parameter.* Refactor away the `Func::lift_results_sync` helper* Use `with_lift_context` in `call_raw`* Simplify a call to `Func::call_unchecked_raw`* Ungate `with_lift_context` to fix non-cm-async build* Fix compile (bad cherry-pick conflict resolution)* Use `with_lower_context` in `call_raw`Trying to unify the async/concurrent paths as much as possible.* Move params out of `call_raw`Let closures capture the params, no need to thread it through as anunnecessary argument.* Clean up unsafety in `Func::call_raw`* Accurately mark `call_raw` itself as `unsafe`, then document why callers should be safe.* Don't have one large `unsafe` block in `call_raw`, instead split it up with separate safety comments.* Move a one-off type definition closer to its use* Avoid intermediate allocations in dynamic calls* Simplify a future-return site* Deduplicate checking parameter count* Simplify a future invocation with `?`* Simplify a variable declaration* Simplify some function signatures* Remove outdated safety comment* Refactor to not require `Params: 'static` on `call_async`* Remove no-longer-necessary SAFETY comment* Fix typos* Add a fast-path with no `Box` for sync host functionsSpeeds up host calls by ~20% and puts them back on parity with thebeforehand numbers Wasmtime has.* Synchronize signatures of async/concurrent dynamic callsUse slices for both instead of vecs for one and slices for the other.Required some slight rejiggering. Apparently one can solve a closureproblem with another closure, then one surely has no more closureproblems.* Fix non-cm-async build---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

beca86b0 - Re-enable concurrent bindings generation tests (#10972)

Mon, 09 Jun 2025 14:15:18 +0000

Re-enable concurrent bindings generation tests (#10972)* Re-enable concurrent bindings generation testsThis commit re-enables tests for bindings generation for concurrentcalls in the main repo after all syncs have now finished with wasip3.This additionally adds some skeleton APIs that the bindings generatoruses which are necessary to get tests passing.* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

29d04b15 - Move the `GetHost` trait used in `bindgen!` into Wasmtime (#10746)

Wed, 07 May 2025 21:02:44 +0000

Move the `GetHost` trait used in `bindgen!` into Wasmtime (#10746)* Move the `GetHost` trait used in `bindgen!` into WasmtimeTurns out we don't actually need to generate this `GetHost` trait, wecan instead have it live in one location with extra documentation. Thereare already extra bounds on the `Host` associated type at all call-sitesso there's no need to additionally have trait bounds in the traitdefinition, meaning the trait definition is always the same and it canmove within Wasmtime.This shouldn't have any impact on any embedders today, it's just movingthings around.* Review comments List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

bb77f602 - wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)

Mon, 21 Apr 2025 21:54:01 +0000

wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)* wasmtime::component: make it possible to typecheck export funcs* wasmtime-wit-bindgen: add typechecking on construction of Indices struct* wit-bindgen: reduce to a single Indices constructor which takes InstancePre* bless bindgen output List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

95cc0297 - Component and Instance have corresponding get_export, get_export_index (#10597)

Wed, 16 Apr 2025 21:38:26 +0000

Component and Instance have corresponding get_export, get_export_index (#10597)* component::Instance: get_export gives a ComponentItem, ExportIndex pairjust like Component::export_index does* align Instance and Component with get_export and get_export_index* fix example* component macro expanded: bless output* fix component model tests* cli only needs get_export_index* code review: deduplicate export to typedef transformation into ComponentItem::from_export List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

f063003e - wasmtime-wit-bindgen: use core instead of std in all emitted code (#10105)

Mon, 27 Jan 2025 15:44:39 +0000

wasmtime-wit-bindgen: use core instead of std in all emitted code (#10105)* wasmtime-wit-bindgen: use core instead of std in all emitted codeprtest:full* wasmtime-component-macro: BINDGEN_TEST_BLESS for changes to macro.* no more use of `std` feature in wasmtime-wit-bindgen and component-macro List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs

636435f1 - async/stream/future support for wasmtime-wit-bindgen (#10044)

Wed, 22 Jan 2025 17:19:46 +0000

async/stream/future support for wasmtime-wit-bindgen (#10044)* async/stream/future support for wasmtime-wit-bindgenI've split this out of #9582 to make review easier.This patch adds async/stream/future/error-context support to the host bindinggenerator, along with placeholder type and function definitions in the`wasmtime` crate which the generated bindings can refer to. Seehttps://github.com/dicej/rfcs/blob/component-async/accepted/component-model-async.md#componentbindgen-updatesfor the design and rationale.Note that I've added temporary `[patch.crates-io]` overrides in Cargo.toml untilhttps://github.com/bytecodealliance/wit-bindgen/pull/1130 andhttps://github.com/bytecodealliance/wasm-tools/pull/1978 have been released.Also note that we emit a `T: 'static` bound for `AsContextMut` whengenerating bindings with `concurrent_imports: true`. This is only because`rustc` insists that the closure we're passing to`LinkerInstance::func_wrap_concurrent` captures the lifetime of `T` despite mybest efforts to convince it otherwise. Alex and I suspect this is a limitationin the compiler, and I asked about it on the rust-lang Zulip, but we haven'tbeen able to determine a workaround so far.Signed-off-by: Joel Dice remove obsolete TODO commentSigned-off-by: Joel Dice make `futures` dep optionalSigned-off-by: Joel Dice update `wasm-tools` and `wit-bindgen`Signed-off-by: Joel Dice * run cargo vetSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/flags_concurrent.rs