Changes in options.rs

c5675cc5 - Consume hostcall fuel when buffering stream data in the host (#12767)

Thu, 12 Mar 2026 21:54:51 +0000

Consume hostcall fuel when buffering stream data in the host (#12767)For guest-to-guest communication stream reads/writes rendezvousingtogether will currently copy data through `Val`. This is expected tobecome more optimized in the future, but for now this needs to consumethe concept of "hostcall fuel" introduced in #12652 to ensure that theguest can't exhaust memory in the host. This additionally tweaks somehostcall fuel calculations to more accurately reflect the size of valueson the host, notably by using `size_of::()` on the host ratherthan the size in the guest.Closes #12674 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

301dc716 - Fix two security advisories. (#12652)

Tue, 24 Feb 2026 18:23:59 +0000

Fix two security advisories. (#12652)* Fix two security advisories.This commit contains merged fixes for two security advisories inWasmtime:* GHSA-852m-cvvp-9p4w* GHSA-243v-98vx-264hThis introduces new knobs to Wasmtime to limit the scope of resourcesthat WASI implementations will allocate on behalf of guests. Unlikebackports to 41.0.x-and-prior these knobs all have default values whichare considered reasonable for hosts if they don't further tune them. Thefollowing CLI knobs have been added:* `-Smax-resources` - limits the total component-model resources a guest can allocate in a table* `-Shostcall-fuel` - a broad limit which enforces that at most this amount of data will be copied from the guest to the host in any one API call (e.g. `string` values can't be too big, `list` can't be quadratic, etc). This fuel is reset on each host function call.* `-Smax-random-size` - the maximal size of the return value of the `get-random-bytes` and `get-insecure-random-bytes` WASI functions.* `-Smax-http-fields-size` - a limit on the size of `wasi:http` `fields` values to avoid infinitely buffering data within the host.The `http` crate has additionally been updated to avoid a panic whenadding too many headers to a `fields` object.Co-authored-by: Mark Bundschuh Co-authored-by: Pat Hickey Co-authored-by: Joel Dice * CI fixes* Run rustfmt* Fix wasi-common build* Fix tests on 32-bit* Fix nightly test expectationsprtest:full---------Co-authored-by: Mark Bundschuh Co-authored-by: Pat Hickey Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

3764e757 - Refactor borrow state tracking for async tasks (#12550)

Tue, 10 Feb 2026 03:15:51 +0000

Refactor borrow state tracking for async tasks (#12550)* Refactor borrow state tracking for async tasksThis commit is a somewhat deep refactoring of how the state of`borrow` is managed for both the host and the guest with respect toasync tasks. This additionally refactors how some async task managementis done for host-called functions.The fundamental problem being tackled here is #12510. In that issue itwas discovered that the way `CallContext`, the borrow tracking mechanismin Wasmtime, is managed is incompatible with async tasks. Specificallythe previous assumption of the scope being mutated for a borrow issomewhere on the call stack is no longer true. It's possible for anasync task to be suspended, for example, and then a sibling task drops aborrow which should update the scope of the suspended task. There were anumber of other small issues I noticed here and there which this PRadditionally has tests for, all of which failed before this change andpass afterwards.The manner in which borrow state is manipulated is a pretty old part ofthe component model implementation dating back to the originalimplementation of resources. I decided to forgo any possible quick fixand have attempted to more deeply refactor and integrate async tasksinto all of this infrastructure. A list of the changes made here are:* The `CallContexts` structure, a stack of `CallContext`, was removed. Tasks now directly store a `CallContext` which is the source of truth for borrow tracking for that call, and it does not move from this location. The store `CallContexts` is now deleted in favor of updating the `Option` in the store to be an `enum` of either concurrent state or a stack. In this manner the old stack-based structure is still used sometimes, but it's impossible to reach when concurrency is enabled.* Entry to the host from guests now reliably pushes a `HostTask` into the store. Previously where a frame were always pushed into a `CallContext` a `HostTask` is pushed into the store. This is still expected to be a bit too expensive for cheap host calls, but it doesn't meaningfully change the performance profile of before.* The `resource_enter_call` and `resource_exit_call` libcalls have been removed. These are now folded into the `enter_sync_call` and `exit_sync_call` libcalls. Emission of these hooks has been updated accordingly. The concept of entering a call more generally has been removed. This is more formally known in the async world as a task starting, so the task creation is now responsible for the demarcation of entering a call. Additionally this means that the concept of exiting a call has somewhat gone away. Instead this method was renamed to `validate_scope_exit` which double-checks that a borrow-scope can be exited but doesn't actually remove the task. Task removal is deferred to preexisting mechanisms.* Management of a `GuestTask`'s previous `Option` field, for example taking/restoring and pushing/popping onto `CallContexts` is now all gone. All related code is outright deleted as the `GuestTask`'s now non-optional `CallContext` field is the source of truth.* The `ConcurrentState` structure now stores a `CurrentThread` enum instead of `Option`. This represents how the currently executing thread could be a host thread, not just a guest thread, which is required for borrow-tracking.* `HostTask` creation in `poll_and_block` and `first_poll`, the two main entrypoints of async host tasks when called by the guest, is now externalized from these functions. Instead these functions assume that the currently running thread is already a `HostTask` of some kind.* In `poll_and_block` the host's result is no longer stored in the guest task but in the host task instead.Overall this enables the `*.wast` test for #12510 to fix the originalissue. This then adds new tests to ensure that cleanup of variousconstructs happens appropriately, such as cancelling a host task shouldclean up its associated resources. Additionally synchronously calling anasync host task no longer leaks resources in a `Store` and shouldproperly clean up everything.There is still more work to do in this area (e.g. #12544) but that'sgoing to be deferred to a future PR at this point.Closes #12510prtest:full* Review comments/CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

98499653 - Move `ResourceTables` constructors to `StoreOpaque` (#12546)

Mon, 09 Feb 2026 20:03:18 +0000

Move `ResourceTables` constructors to `StoreOpaque` (#12546)* Move `ResourceTables` constructors to `StoreOpaque`This is intended to consolidate where they're constructed, provideaccess to the host data at all times, and pave the way for a futurerefactoring here to touch fewer lines.* Fix a cfg List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

cc8d04f4 - Remove need for explicit `Config::async_support` knob (#12371)

Fri, 23 Jan 2026 02:46:45 +0000

Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.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/crates/wasmtime/src/runtime/component/func/options.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/wasmtime/src/runtime/component/func/options.rs

cb97ae85 - allow recursive Wasm invocation from concurrent host functions (#12152)

Thu, 11 Dec 2025 23:03:58 +0000

allow recursive Wasm invocation from concurrent host functions (#12152)* allow recursive Wasm invocation from concurrent host functionsThe core changes here are:- remove an unnecessary assertion from `concurrent::prepare_call`- track instance states (e.g. backpressure, etc.) on a per `(Instance, RuntimeComponentInstanceIndex)` basis - both parts of that key are needed now that concurrent state is tracked on a per-store basis rather than a per-instance basis since `RuntimeComponentInstanceIndex`es are not globally uniqueWhile discussing the above with Alex, we realized the use of a `HashMap` totrack per-instance states was both pessimal and unnecessary. Consequently, I'vefolded that state into `ComponentInstance::instance_handle_tables`, renaming itto `instance_states`. That involved a fair amount of code churn, but doesn'tchange behavior except as described in the second bullet point above.Thanks to Alex for the test case!Fixes #12098Co-authored-by: Alex Crichton Signed-off-by: Joel Dice * use new `RuntimeInstance` type instead of tuplesSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

ec9b62ab - Enable borrowing components and stores mutable at the same time (#11987)

Fri, 07 Nov 2025 19:49:39 +0000

Enable borrowing components and stores mutable at the same time (#11987)* Use `OptionsIndex` more internally in componentsThis updates various runtimes bits for components to use `OptionsIndex`more aggressively and ultimately deletes the old `Options` type. The`Options` type is a heavyweight package of all possible options which iseffectively a duplication of what `OptionsIndex` points to, so that'sremoved in favor of directly accessing options.* Enable borrowing components and stores mutable at the same timeThis commit adds a new, safe, function to the `Instance` type forinternal use in Wasmtime which enables simultaneously borrowing the`Component`-within-the-`Instance` as well as the original store at thesame time. This is not possible to do in safe Rust when the store ismutable and must be implemented with `unsafe` code.The motivation for this commit is performance. In #11974 it wasdiscovered that the addition of a single `Arc::clone` was enough toreduce throughput in the embedding by 20%. While `Arc::clone` isgenerally cheap I can see how a "contended" `Arc::clone` could get quiteexpensive. This particular benchmark was running multiple instances ofthe same component across multiple threads which were all doing manyhost calls. Each host call, after the refactoring of #10959, containedan `Arc::clone` to the component itself. This in turn led to manythreads constantly incrementing/decrementing the `Arc::clone` count ofthe same `Arc` instance.At a high level this clone is not necessary. The component lives withinthe store and cannot be mutated/deleted during execution. Safe Rust,however, forbids access to the component and mutably using the store atthe same time. Thus, this helper function enters the picture. The goalhere is to remove the `Arc::clone` calls without requiring major surgeryor such to refactor the implementations of various functions throughoutWasmtime. The `unsafe` block used to implement this function documentsmore rationale as to why this should be safe.* Update crates/wasmtime/src/runtime/component/instance.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

18aff9aa - Integrate wizer into this repository (#11805)

Mon, 13 Oct 2025 19:33:52 +0000

Integrate wizer into this repository (#11805)* Remove misc wizer-related files* Integrate the Wizer manifest with this repo's workspace* Enable some more wasmtime features* Get wizer tests passing in-repo* Remove duplicate dummy wizer module* Integer `wasmtime wizer` subcommand into the CLI* Fully integrate wizer into `wasmtime` CLI* Split `wasmtime run` into helper functions* Split `Wizer::run` into helper functions* Weave the two together in `wasmtime wizer`The end goal is to have all CLI options in `wasmtime run` applicable for`wasmtime wizer` as well with some light edits between the two. Overallthough we shouldn't have to proactively support commands in one or theother and everything ideally should "just work".* Fix clippy warnings and bench compiles* Fix benchmarks* Create a store-per-iteration* Use the right wasms in the regex benchmark* Get wizer fuzzer building again* Get CLI working again* Run rustfmt* Remove precompiled wasms from the tree35M for some wasms is a bit heavy so instead build them from source.* Update vet configuration for fuzzers/tests* Update publish script with wasmtime-wizer* Fix clippy lint* Some docs and more clippy lintsprtest:full* Relax version requirement* Try to fix asan build* Remove rustflags too* Un-exclude wizer* Adjust publish script* Update lock file after rebase* Integrate bytecodealliance/wizer#139Use deterministic results for relaxed simd operations by default.* Handle preloads in wizer* Appease clippy* Use deterministic relaxed simd in wizer tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

7e39c25e - move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

Mon, 06 Oct 2025 19:53:10 +0000

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)* move `ConcurrentState` from `ComponentInstance` to `Store`This has a few benefits:- No need to specify an instance when creating or piping from a stream or future.- No need to track the instance in an `Accessor`.- You may now execute tasks for multiple instances in a single event loop.The main drawback is that, if one of several instances within a single storetraps, it effectively means all instances have trapped, and the store can't beused to create new instances. The way to avoid that is to use separate storesfor instances which must be isolated from others.As a result of this change, a lot of code had to move from e.g. `impl Instance`to e.g. `impl StoreOpaque`, so the diff is pretty huge, but the changesthemselves are almost entirely non-functional.Fixes #11226Signed-off-by: Joel Dice * fix non-component-model-async buildSigned-off-by: Joel Dice * fix outdated doc commentSigned-off-by: Joel Dice * address review feedback- restore `ComponentStoreData` encapsulation- avoid conditional code duplication in `LiftContext::new`Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

e8189549 - use a single table per instance for resources, waitables, etc. (#11374)

Tue, 12 Aug 2025 20:34:35 +0000

use a single table per instance for resources, waitables, etc. (#11374)* use a single table per instance for resources, waitables, etc.Per https://github.com/WebAssembly/component-model/pull/513, the spec now putsresources, waitables, waitable sets, subtasks, and error contexts in the sametable per instance. This updates the implementation to match.- Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure- Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables`- Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above- Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables`While I was doing table-related things, I also updated `concurrent::Table::new`to reserve the zero handle to mean "invalid". This won't affect what the guestsees in any way, but it allows us to use `TableId::new(0)` to invalidatehost-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`.Fixes #11189Signed-off-by: Joel Dice Re-internalize `ResourceKind` to `mod handle_table`Remove `ResourceKind`Start flattening the representation of `Slot`Internalize `get_mut_handle_by_index`Internalize implementation details such as the representation of slotsto and make methods a bit more targeted in their functionality.Internalize more details of `HandleTable`Don't expose `HandleKind` and of per-function methods for operating onthe various kinds of handles that reside in the table.Flatten the representation of `Slot`There's still some more work to do for host/guest resource handles, butthis helps realize the goal of the previous refactorings in themeantime.* stop using `HandleTable::reps_to_indexes` when delivering eventsPer review feedback, we'd like to get rid of `HandleTable::reps_to_indexes`entirely. This commit doesn't go quite that far, but now we only use it for`error-context` handles. For waitables, which can only be referenced by at mostone guest at a time, we now store the guest handle in `WaitableCommon::handle`and retrieve it from there when delivering an event for that waitable.For `error-context` handles, the spec requirement that we always lower the samehandle for the same `error-context`, combined with the fact that an`error-context` may be referenced by more than one component instance at a time,means we still need some general way to convert a host rep plus component indexinto a handle. Going forward, we could consider either removing that "samehandle" requirement from the spec or consider an alternative implementation(e.g. storing a `HashMap` in the `ErrorContext`host state for keeping track of the handles for each referencing instance.Signed-off-by: Joel Dice * remove `HandleTable::reps_to_indexes`Turns out the spec no longer requires that guests receive the same handle for agiven `error-context` as the one they already have, so we no longer need thisfield -- nor do we need to maintain a per-component-instance reference count.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

4e42487e - optimize host stream/future writes for flat payloads (#11364)

Thu, 31 Jul 2025 19:37:56 +0000

optimize host stream/future writes for flat payloads (#11364)* optimize host stream/future writes for flat payloadsWhen we know statically that a payload will not require any guest realloc callsto lower, there's no need to defer the lowering to a fiber -- we can just do itimmediately.Signed-off-by: Joel Dice * replace `ComponentType::IS_FLAT_TYPE` with `MAY_REQUIRE_REALLOC`Per review comments, this more clearly conveys the purpose of the constant.I've also added a doc comment about what it means and how it is used.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

587ca6f2 - ensure component value lowerings are run on a worker fiber (#11353)

Wed, 30 Jul 2025 20:53:47 +0000

ensure component value lowerings are run on a worker fiber (#11353)* ensure component value lowerings are run on a worker fiberThis is necessary because lowering a component value may require callingrealloc, which may involve epoch interruption, which may require suspending thecurrent fiber. Which obviously doesn't work if we're not running in a fiber.Also, we need to make sure there are no host frames on the stack.Note the use of `Mutex` for `WorkItem::WorkerFunction` and`WorkerItem::Function`. We never lock the mutex -- it's only used to plumbthrough the inner, non-`Sync` value while satisfying the compiler that `Store`is `Sync`.Signed-off-by: Joel Dice * add "we're on a fiber" assertion to `LowerContext::new`Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

815c10de - Package component model options in an index (#11324)

Fri, 25 Jul 2025 19:12:43 +0000

Package component model options in an index (#11324)* Package component model options in an indexThis commit is a refactoring of how canonical ABI options are handledduring compilation and runtime. Previously options were "exploded"meaning that options were all passed around as parameters but this was abummer for a few reasons:* This is `unsafe`-prone as options have raw pointers such as memory and functions. This meant that all functions/operations working with options were fundamentally `unsafe`.* This was unwieldy as the set of options continues to grow larger over time. The `VMLoweringCallee` function previously had 10+ parameters, most of which were canonical ABI options.To solve these two problems options are now intern'd at compile time toan `OptionsIndex`, a 32-bit value. This is stored as a new table incomponent metadata and consulted at runtime. This means that`OptionsIndex` can be passed around with an instance for a much safermeans of threading options around. Additionally there's no need to passaround all parameters individually and instead just one parameter,`OptionsIndex`, need be threaded through.This commit additionally overhauls trampoline generation for thecomponent compiler to avoid a function-per-intrinsic and instead have asingle function that all intrinsics use. I found this easier tounderstand and helps codify that all intrinsics are basically the samewith some minor details differing between them.The end result of this is (hopefully) a net simplification of thecomponent compiler in addition to a large amount of removal of `unsafe`code in the async implementation as only safe types are passed aroundnow instead of raw pointers.Closes #10143Closes #11188* Fill out some TODO comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

2b776b00 - Remove `Arc::clone` when creating `LiftContext` (#11253)

Wed, 16 Jul 2025 16:39:40 +0000

Remove `Arc::clone` when creating `LiftContext` (#11253)A small amount of `unsafe` code is required to enable this but therecent refactorings to use `Pin<&mut ComponentInstance>` everywheremakes this a much easier piece of `unsafe` code to verify. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

fa70f025 - implement Component Model async ABI (#11127)

Fri, 11 Jul 2025 21:06:04 +0000

implement Component Model async ABI (#11127)* implement Component Model async ABIThis commit replaces the stub functions and types in`wasmtime::runtime::component::concurrent` and its submodules with the workingimplementation developed in the `wasip3-prototyping` repo. For ease of review,it does not include any new tests; I'll add those in a follow-up commit.Note that this builds on #11123; only the most recent commit is new.Signed-off-by: Joel Dice * clear params pointer in `call_async` when future is droppedThis ensures that the closure we pass to `prepare_call` will never see a stalepointer.Note that this could potentially be made more efficient; I'm starting with asimple solution, and we can refine from there.Signed-off-by: Joel Dice * Remove unsafety from accessing concurrent async state* Remove a dead variant when async is disabled* Add tests for `tls.rs` unsafe code* Refactor `AbortHandle`* Don't close over the entire future in the `AbortHandle`, instead change it to just the bare minimum state to manage aborts.* Move aborting logic into a helper `AbortHandle::run` function which handles the is-this-aborted-check internally.* Refactor some logic around spawns how `AbortHandle` is managed/created.* Internalize some functions/types* add FIXME comment to `states.rs`Signed-off-by: Joel Dice * reference issue 11190 in `table.rs` TODOSigned-off-by: Joel Dice * switch `use` directives to conventional syntaxSigned-off-by: Joel Dice * remove redundant accessor methodsSigned-off-by: Joel Dice * reference issue 11191 in `yield` TODO commentsSigned-off-by: Joel Dice * replace `dummy_waker` with `Waker::noop`Signed-off-by: Joel Dice * remove obsolete `AsyncState::spawned_tasks` fieldSigned-off-by: Joel Dice * only call post-return automatically for `call_concurrent`This restores the original behavior of requiring explicit post-return calls for`call[_async]` invocations.Signed-off-by: Joel Dice * Favor function arguments before closures* Simplify `watch` a bitMostly move unnecessary state out of the `Arc`.* fix task handle leaks and add test coverageWe weren't always disposing of guest or host task handles once they becameunreachable. This adds a couple of hidden methods which integration tests mayuse to guard against use-after-delete, double-delete, and leak bugs regardingwaitable handles. It also tightens up handle management in `concurrent.rs` toensure those tests pass.Signed-off-by: Joel Dice * Encapsulate type erasure in stream buffersDon't rely on all buffers to handle `TypeId` and assertions and such,instead have a helper type which is the one location of the assertionsand everything else can stay typed.* Remove some methods ending in underscores* Refactor unsafety in `buffers.rs`Mostly move away from raw pointers and instead use utilities like`&[MaybeUninit]`. Also make `WriteBuffer` an `unsafe` trait afterabsorbing the `TakeBuffer` trait. Update all safety-related commentshere and there too.* remove task on drop in `TypedFunc::call_async`This avoids the need for an `Arc`.Signed-off-by: Joel Dice * remove obsolete clause from `FutureReader::read` docsSigned-off-by: Joel Dice * unhide and expand docs for `WriteBuffer` and `ReadBuffer`Signed-off-by: Joel Dice * add optional `component-model-async-bytes` featureThis gates interop with the `bytes` crate, making it optional and non-default.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs

838ed2d0 - Enable `allow_attributes_without_reason` (#11195)

Mon, 07 Jul 2025 21:52:03 +0000

Enable `allow_attributes_without_reason` (#11195)* Enable `allow_attributes_without_reason`This commit enables the `clippy::allow_attributes_without_reason` forthe `wasmtime` crate which previously forcibly allowed it. The reasonthis was allowed was that when the workspace was first migrated theWasmtime crate had too many instances that I was willing to fix. I'venow come back around and tried to fix everything.In short: ideally delete `#[allow]`, otherwise use `#[expect]`,otherwise use `#[allow]`.prtest:full* Adjust some directives* Fix some warnings* Fix stack switching size tests on unix* Don't have a conditional `Drop` impl* Force `testing_freelist` method to be usedToo lazy to write `#[cfg]`, but not too lazy to write a test. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.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/wasmtime/src/runtime/component/func/options.rs

58e295ee - Remove hash tables and bump chunk from the DRC collector (#11175)

Thu, 03 Jul 2025 17:21:12 +0000

Remove hash tables and bump chunk from the DRC collector (#11175)* Remove hash tables and bump chunk from the DRC collectorThis removes the explicit `HashSet`s used to represent theover-approximated-stack-roots and precise-stack-roots sets and replaces themwith an intrusive, singly-linked list and a mark bit in the object headersrespectively. The new list implementation also subsumes the old bump chunk thatsat in front of the old over-approximated-stack-roots hash set.This shaves off about 25% of the time it takes to run the test case inhttps://github.com/bytecodealliance/wasmtime/issues/11141 for me locally.This also ended up being a nice simplification of the DRC collector, which inturn allowed us to further simplify the `GcHeap` trait, since we no longer everneed to GC before passing GC refs into Wasm.Fixes https://github.com/bytecodealliance/wasmtime/issues/11162* Reorder memory operations when pushing onto the over-approximated-stack-roots list* Address some more review feedback* More review feedback* Fix endianness issue with loading reserved bits* Update disas tests after endianness fix List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func/options.rs