Changes in engine.rs

2f7dbd61 - PCC: remove proof-carrying code (for now?). (#12800)

Tue, 31 Mar 2026 04:36:33 +0000

PCC: remove proof-carrying code (for now?). (#12800)In late 2023, we built out an experimental feature calledProof-Carrying Code (PCC), where we attached "facts" to values in theCLIF IR and built verification of these facts after lowering tomachine instructions. We also added "memory types" describing layoutof memory and a "checked" flag on memory operations such that we couldverify that any checked memory operation accessed valid memory (asdefined by memory types attached to pointer values viafacts). Wasmtime's Cranelift backend then put appropriate memory typesand facts in its IR such that all accesses to memory (aspirationally)could be checked, taking the whole mid-end and lowering backend ofCranelift out of the trusted core that enforces SFI.This basically worked, at the time, for static memories; but never fordynamic memories, and then work on the feature lostprioritization (aka I had to work on other things) and I wasn't ableto complete it and put it in fuzzing/enable it as a production option.Unfortunately since then it has bit-rotted significantly -- as we addnew backend optimizations and instruction lowerings we haven't keptthe PCC framework up to date.Inspired by the discussion in #12497 I think it's time to deleteit (hopefully just "for now"?) unless/until we can build it again. Andwhen we do that, we should probably get it to the point of validatingrobust operation on all combinations of memory configurations beforemerging. (That implies a big experiment branch rather than a bunch ofeager PRs in-tree, but so it goes.) I still believe it is possible tobuild this (and I have ideas on how to do it!) but not right now. List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

7357e7c9 - Use `try_new::>` in `Engine::load_code` (#12607)

Tue, 17 Feb 2026 21:24:58 +0000

Use `try_new::>` in `Engine::load_code` (#12607) List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

f248b5c0 - Config knobs and validation for record-replay (#12375)

Mon, 02 Feb 2026 04:30:42 +0000

Config knobs and validation for record-replay (#12375) List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

17899c88 - Share empty `ModuleRuntimeInfo`s across all stores in an engine (#12409)

Fri, 23 Jan 2026 21:01:54 +0000

Share empty `ModuleRuntimeInfo`s across all stores in an engine (#12409)* Share empty `ModuleRuntimeInfo`s across all stores in an engineThis avoids an `Arc`- and `Box`-allocation during `Store` creation.* Fix no-runtime build* Pin x86-64_macos build to nightly to avoid a rustc bug List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.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/engine.rs

a0525691 - Handle OOM in `Engine::new` (#12362)

Wed, 21 Jan 2026 19:36:46 +0000

Handle OOM in `Engine::new` (#12362)Part of https://github.com/bytecodealliance/wasmtime/issues/12069 List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.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/engine.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/engine.rs

9bb96d51 - Add `Config::without_compiler` (#12089)

Tue, 02 Dec 2025 23:50:13 +0000

Add `Config::without_compiler` (#12089)* Add `Config::without_compiler`This provides us an allocation-free path for constructing a `Config`.Why not rely on builds when `cfg(not(any(feature = "cranelift", feature ="winch")))`? Because we need to test our various OOM-handling andallocation-free code paths in this workspace, and without some way to create aconfig without a compiler otherwise, cargo's feature resolver will enable thosefeatures in the workspace, enabling the compiler in the config, but we don'tintend to make compiler configurations handle OOM.* Quiet unused mut warnings* Move default compiler flags into builder List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

c9bf1442 - Fix compiler inlining tunables (#11797)

Mon, 06 Oct 2025 21:03:51 +0000

Fix compiler inlining tunables (#11797)* Fix compiler inlining tunablesFixes https://github.com/bytecodealliance/wasmtime/issues/11784* fix no-compiler warning List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

2a2e8f62 - Couple cleanups to the flags/settings handling in Cranelift (#11744)

Wed, 01 Oct 2025 14:17:11 +0000

Couple cleanups to the flags/settings handling in Cranelift (#11744)* Remove unused shared flags* Get rid of predicate settingsThey were important in the old backend framework, but with the newbackend framework if we need a combination of multiple settings, thatcan just be done as a regular extractor doing &&. This simplifies thesettings implementation. List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.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/wasmtime/src/engine.rs

c7dc2d52 - Disallow loading code on `x86_64-unknown-none` (#11553)

Thu, 28 Aug 2025 19:13:26 +0000

Disallow loading code on `x86_64-unknown-none` (#11553)* Disallow loading code on `x86_64-unknown-none`... And then also add an escape hatch to allow loading code. This commitis the culmination of discussion on #11506 with a proposed resolutionfor Wasmtime. The resolution being:* Wasmtime will reject loading code on `x86_64-unknown-none` platforms by default.* A new `Config::x86_float_abi_ok` escape hatch is added to bypass this check.* Documentation/errors are updated around `x86_float_abi_ok` to document the situation.* The `min-platform` example is updated to showcase how this is valid to run in that particular embedding (aka enable more features and sufficiently detect said features).The basic tl;dr; is that we can't detect in stable Rust what float ABIis being used so therefore we pessimistically assume that`x86_64-unknown-none` is using a soft-float ABI. This is incompatiblewith libcalls unless they aren't actually called which is only possiblewhen sufficiently many target features are enabled.The goal of this commit is to be a relatively low-effort way to place aroadblock in the way of "ok ABIs are weird" but at the same time enablegetting around the roadblock easily. Additionally the roadblock pointsto documentation about itself to learn more about what's going on here.Closes #11506* Add audit of raw-cpuid* Add back in checkTurns out it doesn't go through the same path as other bits* Review comments* Fix running floats without without custom support List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

becdee57 - Add PoolingAllocatorMetrics (#11490)

Fri, 22 Aug 2025 16:04:42 +0000

Add PoolingAllocatorMetrics (#11490)This exposes some basic runtime metrics derived from the internal stateof a `PoolingInstanceAllocator`.Two new atomics were added to PoolingInstanceAllocator: `live_memories`and `live_tables`. While these counts could be derived from existingstate it would require acquiring mutexes on some inner state. List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.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/engine.rs

3ecb338e - Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)

Tue, 29 Jul 2025 14:32:54 +0000

Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilationThis commit plumbs together two pieces of recently-added infrastructure:1. function inlining in Cranelift, and2. the parallel bottom-up inlining scheduler in Wasmtime.Sprinkle some very simple inlining heuristics on top, and this gives us functioninlining in Wasm compilation.The default Wasmtime configuration does not enable inlining, and when we doenable it, we only enable it for cross-component calls by default (sincepresumably the toolchain that produced a particular core Wasm module, like LLVM,already performed any inlining that was beneficial within that module, but thattoolchain couldn't know how that Wasm module would be getting linked togetherwith other modules via component composition, and so it could not have done anycross-component inlining). For what it is worth, there is a config knob toenable intra-module function inlining, but this is primarily for use by ourfuzzers, so that they can easily excercise and explore this new inliningfunctionality.All this plumbing required some changes to the `wasmtime_environ::Compiler`trait, since Winch cannot do inlining but Cranelift can. This is mostlyencapsulated in the new `wasmtime_environ::InliningCompiler` trait, for the mostpart. Additionally, we take care not to construct the call graph, or any otherdata structures required only by the inliner and not regular compilation, bothwhen using Winch and when using Cranelift with inlining disabled.Finally, we add a `disas` test to verify that we successfully inline a series ofcalls from a function in one component, to a cross-component adapter function,to a function in another component. Most test coverage is expected to come fromour fuzzing, however.* Fix dead code warning when not `cfg(feature = "component-model")`* fix winch trampoline compilation* Move CLI options to codegen* Move parameters into struct* Use an index set for call-graph construction* Smuggle inlining heuristic options through cranelift flags* Remove old CLI flags* set tunables before settings* Only configure inlining options for cranelift in fuzzing List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

037a6eda - s390x: Refactor hardware facility detection (#11220)

Fri, 11 Jul 2025 15:35:53 +0000

s390x: Refactor hardware facility detection (#11220)This patch implements a number of changes relating to s390x HWfacilities and facility detection:- Fix a mis-named facility: the z15 (arch13) CPU introduced the Miscellaneous-Instruction-Extensions Facility *3* (not 2). Rename "mie2" to "mie3" throughout the code base.- Now that we can use inline asm, use the STORE FACILITY LIST EXTENDED instruction rather than HWCAP to detect facilities at run time. This eliminates the libc crate dependency, and allows for more fine-grained feature detection.- Add support for the z16 (arch14) CPU names (these do not provide any facilities that would be relevant to cranelift, but it should be possible to use these names as synonyms to z15 at least).- Add support for the z17 (arch15) CPU names, and two new facilities provided at this level: the Miscellaneous-Instruction-Extensions Facility 4 and the Vector-Enhancements Facility 3. (Note that no code to exploit these facilities is present in this patch; that will be provided later.) List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.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/engine.rs

ab44e321 - fix: do not collect backtrace on each `gc_runtime` access (#11068)

Wed, 18 Jun 2025 22:35:22 +0000

fix: do not collect backtrace on each `gc_runtime` access (#11068)Signed-off-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs

63d482c8 - Stack switching: Infrastructure and runtime support (#10388)

Wed, 04 Jun 2025 22:47:35 +0000

Stack switching: Infrastructure and runtime support (#10388)* [pr1] base* prtest:full* make sure to use ControlFlow result in trace_suspended_continuation* stack-switching: cleanup: remove stray c-api changesThese are remnants of unrelated wasmfx wasmtime experiments, possiblysuitable for later submission against upstream.* stack-switching: reuse async_stack_size* stack-switching: delete delete_me debugging* stack-switching: address feedback in environ::types* stack-switching: remove unused code from vmoffsets* stack-switching: drop dependency on std* stack-switching: add compilation checks to ci matrix* stack-switching: remove debug_println cruft* stack-switching: export environ consts consistently* stack-switching: export vm pub items consistently* table_pool: reduced capacity for large elementsVMContRef elements which takes up two words and we don't want todouble the size of all tables in order to support storing these.This change changes the table to target storing the requestedmax number of elements if they are "nominally" sized with(potentially) reduced capacity for non-nominally sized types whenencountered.Continuations are the only type of element which may result infewer table slots being available than requested.* stack-switching: extend conditional compilationA fair bit of the definitions for stack switching are stillenabled, but this patch takes things a bit further to avoidcompilation problems; notably, cont_new is now not compiledin unless the feature is enabled.* stack-switching: formatting fixes* stack-switching: address new clippy checksIn addition, to get clippy to fully pass, plumbed inadditional config to make winch paths happy; there's noimpl for winch yet but plumbing through the feature isrequired to make paths incorporating macros at variouslayers satisfied (and it is expected we'll use thefeatures in the future).* stack-switching: more conditional compilation fixes* stack-switching: additional conditional compile on table builtins for continuations* stack-switching: additional conditional compile fixes* stack-switching: additional conditional compile in store* stack-switching: remove overly strict assertion* stack-switching: remove errantly dropped no_mangle in config c-api* stack-switching: VMContObj::from_raw_parts* stack-switching: remove duplicate async_stack_size feature check* stack-switching: VMArray -> VMHostArray* stack-switching: remove unnecessary clippy exception* stack-switching: fix docs referenced VMRuntimeLimits* stack-switching: fix doc typo* stack-switching: follow recommendations for type casts* stack-switching: use usize::next_multiple_of* stack-switching: update outdated comment* stack-switching: use feature gate instead of allow(dead_code)* stack-switching: rework backtrace using chunks/zip* stack-switching: move tests to footer moduleThis is a bit more consistent with the prevailing stylein tree and (subjectively) makes finding the testsas a reader more straightforward.Tests left unchanged sans some import cleanup.* stack-swictchding: verify stack_chain offsets at runtime* fixup! stack-switching: use feature gate instead of allow(dead_code)* stack-switching: document continuation roots tracing using match arms---------Co-authored-by: Paul Osborne List of files: /wasmtime-44.0.1/crates/wasmtime/src/engine.rs