Changes in store.rs

e4305755 - Add wasi:http support to the C API (#12950)

Fri, 03 Apr 2026 16:41:51 +0000

Add wasi:http support to the C API (#12950) List of files: /wasmtime-44.0.1/crates/c-api/src/store.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/c-api/src/store.rs

cde2e04f - Fill out more of the C++ API for components (#11889)

Tue, 21 Oct 2025 19:27:10 +0000

Fill out more of the C++ API for components (#11889)* capi: Add a C++ API for `component::Linker`Just a bare-bones API for now with functionality that's possible to fillout. Notably instantiation and defining functions is not yet possible inC++. Some more feature-parity is also added with the core linkers aswell.* capi: Add bindings for component instances* capi: Delete wasip2.h header fileUpon reflection I realize that this is not actually necessary and isotherwise a duplicate of the functionality in `wasi.h`. All of thefunctionality in `wasi.h` is already supported to power WASIp2-definedAPIs in a linker, which is enabled by the `WasiView` trait redirectingto the `WasiView for WasiP1Ctx` implementation. This is similar to howthe `wasmtime` CLI works where a P1 context is always created and thenit's conditionally used for either core wasm or components.Effectively this is a deletion of duplicate functionality in the C APIbut no underlying functionality is lost. Translating information topreexisting WASI calls will work the same as using the wasip2 APIs before.* capi: Start bindings for component functions* capi: Bind component values in the C++ API* capi: Finish bindings for component functions/linkersAll the pieces are now in place to use the C++ API in testing.* Fix compilation of CLI* Fix compile on MSVC* Try again to fix msvc compat* Fix `get_f32` and `get_f64` return values* Fix signed return values* Remove no-longer-needed `capi_transfer` function* Try to fix msvc again* Remove std::optional constructor of `Val`* Fix another namespace clash on msvc* One day I surely may understand a fraction of either C++ or MSVC, buttoday is not that day.* Document internal macro* Add other internal docs List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

4ac219fd - Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}" (#11380)

Tue, 05 Aug 2025 18:48:22 +0000

Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}" (#11380)* Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}"This commit renames the `preview1` module and features to `p1` and doesthe same for `preview0`. This additionally cleans up the test suite abit to share more code amongst all the implementaitons and to also movethe p1 tests out of the p2 folder.This additionally adds a `p2` feature to the `wasmtime-wasi` crate butit does not currently gate the `p2` module because that'll require somemore refactoring an annotations to get that working.* Fix build of the CLI* Fix build of the C API* Fix bench-api build* Fix build of examples* More renamings List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

f7a5aa34 - Unify WASIp{2,3} context structures (#11370)

Sat, 02 Aug 2025 00:57:09 +0000

Unify WASIp{2,3} context structures (#11370)This removes `wasmtime_wasi::p{2,3}::{WasiCtx, WasiCtxBuilder,WasiView}` in favor of only having `wasmtime_wasi::{WasiCtx,WasiCtxBuilder, WasiView}` instead. Conceptually these revisions of WASIall provide the same functionality just with a different veneer that thecomponent model offers, so having only one way to configure host-sidebehavior will make it easier to both organize implementations internally(e.g. more sharing of code) as well as for embedders to configure (onlyone context to create/manage). List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

0a074afc - Simplify WASI internal implementations (#11365)

Fri, 01 Aug 2025 01:24:24 +0000

Simplify WASI internal implementations (#11365)* Simplify WASI internal implementationsThis commit migrates the WASIp2 implementation to be closer to theupcoming WASIp3 implementation in terms of how things are implementedinternally. Previously the way things worked with WASIp2 is:* Embedders call `add_to_linker` with `T: WasiView`* Internally `add_to_linker` is called which creates `WasiImpl<&mut T>`* All internal implementations were `impl Host for WasiImpl where T: WasiView`* A forwarding impl of `impl WasiView for &mut T` was requiredWhile this all worked it's a bit complicated for a few reasons:1. Dealing with generically named structures like `WasiImpl` (or `IoImpl` or `WasiHttpImpl`) is a bit baroque and not always obvious as to what's going on.2. The extra layer of generics in `impl Host for WasiImpl` adds a layer of conceptual indirection which is non-obvious.3. Other WASI proposal implementations do not use this strategy and instead use "view" types or `impl Host for TheType` for example.4. Internal incantations of `add_to_linker` had to deal with mixtures of `IoImpl` and `WasiImpl` and aligning everything just right.5. An extra layer of generics on all impls meant that everything was generic meaning that `wasmtime-wasi`-the-crate didn't generate much code, causing longer codegen times for consumers.The goal of this commit is to migrate towards the style of what WASIp3is prototyping for how impls are modeled. This is done to increase theamount of code that can be shared between WASIp2 and WASIp3. This has anumber of benefits such as being easier to understand and also beingmore modular where `wasi:clocks` implementations of traits don't requirefilesystem context to be present (as is the case today). This in theoryhelps a more mix-and-match paradigm of blending together various bitsand pieces of `wasmtime-wasi` implementations.Concretely the changes made here are:* `WasiView` no longer inherits from `IoView`, they're unrelated traits now.* `WasiView` now returns `WasiViewCtx<'a>` which has `ctx: &'a mut WasiCtx` and `table: &'a mut ResourceTable`. That means it basically does the same thing before but in a slightly different fashion.* Implementations of `Host` traits are now directly for `WasiCtxView<'_>` and don't involve any generics at all. These are hopefully easier to understand and also better from a codegen/compile-time perspective.* Embedders no longer need to implement `IoView` directly and instead fold that functionality into `WasiView`.* `WasiHttpView` no longer inherits from `IoView` and instead has a direct `fn table` method. Additionally `WasiHttpImpl` no longer embeds `IoImpl` inside of it.* Host traits for `wasi:io` are now implemented directly for `ResourceTable` instead of `IoImpl`.The immediate goal of this refactoring is to enable more sharing alongthe lines of #11362. This was not possible prior because WASIp3 requiresa simultaneous borrow on the table/ctx while the trait hierarchypreviously gave you one-or-the-other. With this new organization it willbe possible to get both at the same time meaning morestructure/contexts/etc can be shared between implementations.prtest:full* CI fixes* More CI fixes* More CI fixes List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

69c01c5d - c-api: component-model: Resource table, WASI (#11055)

Wed, 18 Jun 2025 15:05:39 +0000

c-api: component-model: Resource table, WASI (#11055)* c-api: component-model: Resource table, WASI* WASIP2 context builder* Add include* Rename function* Add a simple test* Add comments prtest:full List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

703871a2 - Enable the `useless_conversion` Clippy lint (#10838)

Tue, 27 May 2025 16:49:22 +0000

Enable the `useless_conversion` Clippy lint (#10838)* Enable the `useless_conversion` Clippy lintWe've got lots of types in Wasmtime and convert between them quite alot, but often over time conversions become unnecessary throughrefactorings or similar. This will hopefully enable us to clean up someconversions as they come up to try to have as few as possible ideally.* Review comments List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

c22b3cb9 - Reuse Wasm linear memories code for GC heaps (#10503)

Fri, 11 Apr 2025 21:15:55 +0000

Reuse Wasm linear memories code for GC heaps (#10503)* Reuse code for Wasm linear memories for GC heapsInstead of bespoke code paths and structures for Wasm GC, this commit makes itso that we now reuse VM structures like `VMMemoryDefinition` and bounds-checkinglogic. Notably, we also reuse all the associated bounds-checking optimizationsand, when possible, virtual-memory techniques to completely elide them.Furthermore, this commit adds support for growing GC heaps, reusing themachinery for growing memories, and makes it so that GC heaps always start outempty. This allows us to properly delay allocating the GC heap's storage until aGC object is actually allocated.Fixes #9350* fix c api compilation* use assert_contains* remove no-longer-necessary extra memory config from limiter tests* Helper for retry-after-maybe-async-gc in libcalls* Clean up some comments* fix wasmtime-fuzzing and no-gc compilation* fix examples* fix no-gc+compiler build* fix build without pooling allocator* fix +cranelift +gc-drc -gc-null builds* fix table hash key stability test* fix oracle usage of `ExternRef::new`* fix +gc -gc-null -gc-drc build* fix wasmtime-fuzzing* make `StorePtr` wrap a `NonNull`* Fix some doc tests* Remove some unnecessary retry helpers now that `FooRef::new` will auto-gc* fix things after rebase* Reorganize collection/growth methods for GC heap* rename BoundsCheck variants* fix cfg'ing of gc only code* Fix doc tests* fix one more gc cfg* disable GC heap OOM test on non-64-bit targets List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

ae84e6ed - Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

Thu, 09 Jan 2025 21:05:55 +0000

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)* Enable `unsafe-attr-outside-unsafe` 2024 edition lintThis commit enables the `unsafe-attr-outside-unsafe` lint in rustc usedin transitioning to the 2024 edition. This requires that the`#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`.This mostly affects the C API of wasmtime and most of the changes hereare a simple search/replace.* Another attribute update* Fix command adapter build List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

df69b9a7 - Implement the table64 extension to the memory64 proposal (#9206)

Wed, 11 Sep 2024 17:34:31 +0000

Implement the table64 extension to the memory64 proposal (#9206)This commit implements the table64 extention in both Wasmtime andCranelift.Most of the work was changing a bunch of u32 values to u64/usize.The decisions were made in align with the PR #3153 whichimplemented the memory64 propsal itself.One significant change was the introduction of `IndexType`and `Limits` which streamline and unify the handling of limitsfor both memories and tables.The spec and fuzzing tests related to table64 are re-enabled whichprovides a good coverage of the feature. List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

0c62d931 - wasmtime-c-api: switch from wasi-common to wasmtime-wasi (#8066)

Fri, 12 Apr 2024 20:54:53 +0000

wasmtime-c-api: switch from wasi-common to wasmtime-wasi (#8066)* wasmtime-c-api: switch from using wasi-common to wasmtime-wasi* Fix WasiP1Ctx references, and stop eagerly opening dirs for preopens* Add OutputFile to skip async writes in stdout/stderr---------Co-authored-by: Trevor Elliott List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

420fc3d1 - c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs (#8344)

Fri, 12 Apr 2024 14:35:48 +0000

c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs (#8344)This renames some types and adds some type aliases to help us better distinguishbetween `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-relatedtypes. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is relatedto `wasmtime.h`.* `StoreRef` -> `WasmStoreRef`* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases* `StoreData` -> `WasmtimeStoreData`* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`* Introduce the `Wasmtime{Store,Caller}` aliases List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

2b00a541 - Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)

Tue, 13 Feb 2024 17:57:58 +0000

Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)* WIP: try to make wasi-common self contained.* rebase: cargo.lock* remove all dependencies between wasi-common and wasmtime-wasi* use wasi-common directly throughout tests, benches, examples, cli run* wasi-threads: use wasi-common's maybe_exit_on_error in spawned threadnot a very modular design, but at this point wasi-common andwasi-threads are forever wed* fix wasmtime's docs* re-introduce wasmtime-wasi's exports of wasi-common definitions behind deprecated* factor out determining i32 process exit codeand remove libc dep because rustix provides the same constant* commands/run: inline the logic about aborting on trapsince this is the sole place in the codebase its used* Add high-level summary to wasi-common's top-level doc comment.* c-api: fix use of wasi_cap_std_sync => wasi_common::sync, wasmtime_wasi => wasi_common* fix tokio example* think better of combining downcast and masking into one method* fix references to wasmtime_wasi in docsprtest:full* benches: use wasi-common* cfg-if around use of rustix::process because that doesnt exist on windows* wasi-common: include tests, caught by verify-publish* fix another bench* exit requires wasmtime dep. caught by verify-publish. List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

28fd6bf3 - c-api: support yielding in wasmtime_store_epoch_deadline_callback (#7476)

Mon, 06 Nov 2023 15:50:01 +0000

c-api: support yielding in wasmtime_store_epoch_deadline_callback (#7476)* c-api: reuse CallbackDataPtrSigned-off-by: Tyler Rockwood * c-api: support yielding in epoch deadline callbackSigned-off-by: Tyler Rockwood * Use triple slash doc commentsprtest:full* c-api: guard yield behind async cfg flagSigned-off-by: Tyler Rockwood * c-api: prevent dead code warnings with no default featuresSigned-off-by: Tyler Rockwood ---------Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

85c0a2df - Switch to simpler fuel APIs (#7298)

Mon, 23 Oct 2023 19:50:23 +0000

Switch to simpler fuel APIs (#7298)In an effort to simplify the many fuel related APIs, simplify theinterface here to a single counter with get and set methods.Additionally the async yield is reduced to an interval of the total fuelinstead of injecting fuel, so it's easy to still reason about how muchfuel is left even with yielding turned on.Internally this works by keeping two counters - one the VM uses toincrement towards 0 for fuel, the other to track how much is in"reserve". Then when we're out of gas, we pull from the reserve torefuel and continue. We use the reserve in two cases: one for overflowof the fuel (which is an i64 and the API expresses fuel as u64) and theother for async yieling, which then the yield interval acts as a cap tohow much we can refuel with.This also means that `get_fuel` can return the full range of `u64`before this change it could only return up to `i64::MAX`. This isimportant because this PR is removing the functionality to track fuelconsumption, and this makes the API less error prone for embedders totrack consumption themselves.Careful to note that the VM counter that is stored as `i64` can bepositive if an instruction "costs" multiple units of fuel when the fuelran out.prtest:fullSigned-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

1c2e5104 - Support reset_fuel in store APIs (#7240)

Mon, 16 Oct 2023 17:39:24 +0000

Support reset_fuel in store APIs (#7240)* Support set_fuel in store APIsFixes: https://github.com/bytecodealliance/wasmtime/issues/5109Signed-off-by: Tyler Rockwood * rename set_fuel to reset_fuelTo make it more clear that consumed fuel is being reset.Signed-off-by: Tyler Rockwood * update out of date documentation for fuel in C APISigned-off-by: Tyler Rockwood ---------Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs

1d4686de - Allow async yield from epoch interruption callback (#6464)

Fri, 02 Jun 2023 20:15:46 +0000

Allow async yield from epoch interruption callback (#6464)* Allow async yield from epoch interruption callbackWhen an epoch interruption deadline arrives, previously it was possibleto yield to the async executor, or to invoke a callback on the wasmstack, but not both. This changes the API to allow callbacks to run andthen request yielding to the async executor.* Fix Wasmtime C API implementation List of files: /wasmtime-44.0.1/crates/c-api/src/store.rs