Changes in lib.rs

4a168844 - Fix some minor `bindgen!` issues with `anyhow: true` (#12657)

Tue, 24 Feb 2026 23:36:26 +0000

Fix some minor `bindgen!` issues with `anyhow: true` (#12657)* Fix some minor `bindgen!` issues with `anyhow: true`Found when updating Spin to Wasmtime 42.0.0 where some cases weren'thandled:* Trappable functions with no result.* Resource destructors.* Functions with custom trappable errors.* Shuffle some features List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

55207c6f - Remove doc of cargo `signals-based-traps` feature (#12643)

Mon, 23 Feb 2026 20:13:24 +0000

Remove doc of cargo `signals-based-traps` feature (#12643)This was removed awhile back, so remove the misleading documentation.Closes #12634 List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

b8f882d1 - Add support for fine-grained operator costs (#11572) (#12541)

Thu, 19 Feb 2026 19:37:54 +0000

Add support for fine-grained operator costs (#11572) (#12541)Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuringper-operator fuel costs via `Config::operator_cost`. Previously, operatorcosts were hardcoded inline in both Cranelift and Winch code generation.Now the cost logic is centralized in `wasmtime-environ` and referencedfrom both backends via `tunables.operator_cost.cost(op)`.`OperatorCostStrategy` is an enum with two variants:- `Default`: reproduces the original hardcoded behavior (nop/drop/control flow cost 0, everything else costs 1).- `Table(Box)`: a per-operator cost table generated via `wasmparser::for_each_operator!`.Because `OperatorCostStrategy::Table` contains a `Box`, the type has adestructor. This makes `Tunables` non-trivially droppable, which preventsusing the `..Tunables::default_miri()` functional update syntax in constfunctions (E0493). To work around this, `default_miri`, `default_u32`,and `default_u64` are changed to non-const fns. None ofthese are called in const contexts, except in tests. List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

f44d1e46 - Use `wasmtime_environ::collections::HashSet` in the `TypeRegistry` (#12522)

Wed, 04 Feb 2026 19:38:28 +0000

Use `wasmtime_environ::collections::HashSet` in the `TypeRegistry` (#12522)* Use `wasmtime_environ::collections::HashSet` in the `TypeRegistry`* silence warning in certain build cfgs List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

40215f21 - Adjust Wasmtime's prelude/hash collections (#12509)

Tue, 03 Feb 2026 22:23:55 +0000

Adjust Wasmtime's prelude/hash collections (#12509)This commit updates Wasmtime's internal usage of hash maps and hash setsto use the standard library when the `std` feature is enabled, asopposed to using `hashbrown`. When `std` is disabled `hashbrown` isstill used, however. Additionally the prelude of `wasmtime` is now asimple reexport of `wasmtime_environ`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.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/lib.rs

9a874100 - Fix generated code for `anyhow: true` in wit-bindgen (#12334)

Tue, 13 Jan 2026 22:00:07 +0000

Fix generated code for `anyhow: true` in wit-bindgen (#12334)* Fix generated code for `anyhow: true` in wit-bindgenThe trait was still declared as using `wasmtime::Result`. It now uses`wasmtime::anyhow::Result` and we re-export `anyhow` through `wasmtime::anyhow`-- with `doc(hidden)` since it is only for macro-generated code -- when the`anyhow` cargo feature is enabled.* Fix macro expansion test expectations List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

c3a6060b - Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)

Tue, 13 Jan 2026 18:04:34 +0000

Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)* Polyfill `ToWasmtimeResult` and add eventually-necessary call sitesThis commit polyfills `wasmtime_internal_error::ToWasmtimeResult` in`wasmtime_environ`, adds the cargo feature plumbing that will eventually connectto the `"wasmtime_internal_error/anyhow"` cargo feature but for now justconfigures this polyfill, and adds uses of the polyfill at all the sites thatwill be necessary once we swap out `anyhow` for`wasmtime_internal_error`. Currently, the polyfill is just an identity function,because `wasmtime::Result`/`wasmtime_environ::error::Result` is just anothername for `anyhow::Result`. Once we do move away from `anyhow`, however, thatwill no longer be the case, and these uses will do the necessary conversion.My goal with landing this as an incremental commit is to make it so that theactual commit that does the error crate swap out can be as close to _just_ the`Cargo.toml` dependency change, without any other code changes as much aspossible. This, in turn, means that swap out should be super easy to revert, ifnecessary.* Add a couple more `.to_wasmtime_result()` invocations in fuzz code* Revert "Add a couple more `.to_wasmtime_result()` invocations in fuzz code"This reverts commit b33696e5f63f7eed731ca9dad10fec5e55a550d3.* Move cranelift fuzz targets back to anyhow* Fix cargo feature enablement for explorer List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

ff33e949 - Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)

Fri, 09 Jan 2026 19:23:56 +0000

Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)We are trying to move to `format_err!` instead. List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.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/wasmtime/src/lib.rs

778771d2 - Update nightly rust used in CI (#11856)

Wed, 15 Oct 2025 15:47:02 +0000

Update nightly rust used in CI (#11856)* Update nightly rust used in CIA few more warnings are cropping up so squash them.* Frob the `unreachable_code` lintLooks like nightly rust has gotten much more aggressive about linting onunreachable code.prtest:full* Allow some more warnings... List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

4f2fa154 - Update nightly Rust used in CI (#11755)

Mon, 29 Sep 2025 18:12:14 +0000

Update nightly Rust used in CI (#11755)* Update nightly Rust used in CIKeeping it up-to-dateprtest:full* Fix unused warnings on nightly* Rename rustdoc feature* Adjust some removals List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

8d4e9234 - Resolve `unsafe_op_in_unsafe_fn` in `wasmtime` crate (#11432)

Thu, 14 Aug 2025 14:22:41 +0000

Resolve `unsafe_op_in_unsafe_fn` in `wasmtime` crate (#11432)Just a few unsafe blocks remainCloses #11180 List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.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/lib.rs

b63c25ae - fix(no_std)!: respect `std` feature when target is windows/unix (#11152)

Thu, 03 Jul 2025 22:07:42 +0000

fix(no_std)!: respect `std` feature when target is windows/unix (#11152)* fix(no_std)!: respect `std` feature when target is windows/unixBREAKING CHANGE: the fix disables standard features for dependents that use wasmtime with `default-features = false`.* fix cargo check workflow* Don't require `std` feature for invalid faultsFill out the `compile_error!` to avoid failing a build.* addressing review comments* add `std` to `stack-switching` feature* remove `rustix/mm` from `std` feature dependencies* add `std` feature flag to `jit-icache-coherence`- The `std` feature gates the use of standard library for icache coherence in Windows; otherwise, defaults to the `libc` implementation.- The `std` feature of Wasmtime now depends on the `wasmtime-jit-icache-coherence/std`* Only include jit-icache-coherence on `std` buildsprtest:full* Fix some idiom issues* More idiom issues* Require `std` for loading native code---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

0ffa7455 - Update cache configuration documentation and references (#10859)

Thu, 29 May 2025 16:59:04 +0000

Update cache configuration documentation and references (#10859)Remove references to deprecated cache config methods and update to use the new simplified `Config::cache` API. Also remove the mandatory `enabled` field from cache configuration documentation since all cache settings are now optional. List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.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/wasmtime/src/lib.rs

073aedab - Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

Wed, 09 Apr 2025 21:06:59 +0000

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)* Enable the `unsafe-op-in-unsafe-fn` lintThis commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for theentire workspace. This lint will be warn-by-default in the 2024 editionso this is intended to smooth the future migration to the new edition.Many `unsafe` blocks were added in places the lint warned about, withtwo major exceptions. The `wasmtime` and `wasmtime-c-api` crates simplyexpect this lint to fire and effectively disable the lint. They're toobig at this time to do through this PR. My hope is that one day in thefuture they'll be migrated, but more realistically that probably won'thappen so these crates just won't benefit from this lint.* Fix nostd fiber buildprtest:full* Fix build on Windows* Fix asan build List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

e60b6e62 - Enable warnings if `cranelift` is disabled (#10157)

Thu, 30 Jan 2025 19:01:23 +0000

Enable warnings if `cranelift` is disabled (#10157)Continuation of work in #10131. List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs

a727985c - Enable warnings if `gc` is disabled (#10149)

Thu, 30 Jan 2025 16:55:15 +0000

Enable warnings if `gc` is disabled (#10149)* Enable warnings if `gc` is disabledContinuation of work in #10131. This additionally handles turning off`gc-null` and `gc-drc` and the various combinations within.* Fix some more warnings* Fix a feature combo build List of files: /wasmtime-44.0.1/crates/wasmtime/src/lib.rs