Changes in const_expr.rs

a6f4bd2f - Deduplicate const-eval fast paths in Wasmtime (#12406)

Fri, 23 Jan 2026 17:45:22 +0000

Deduplicate const-eval fast paths in Wasmtime (#12406)Closes #12243 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.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/vm/const_expr.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/runtime/vm/const_expr.rs

99ecf728 - Debug: create private code memories per store when debugging is enabled. (#12051)

Wed, 03 Dec 2025 01:18:00 +0000

Debug: create private code memories per store when debugging is enabled. (#12051)* Debug: create private code memories per store when debugging is enabled.This will allow patching code to implement e.g. breakpoints. (That is,for now the copies are redundant, but soon they will not be.)This change follows the discussion [here] and offline to define a fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function's bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.The only case where we return raw code pointers to the `EngineCode`directly have to do with Wasm-to-array trampolines: in some cases, e.g.`InstancePre` pre-creating data structures with references to hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-to-array trampolines never bake in direct calls to Wasm functions;the strong invariant is that Wasm functions never execute from`EngineCode` directly. Some parts of the component runtime would alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual to the range -- 0-up-to-PC and last entry found).[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812* Review feedback: do not assume a reasonable code alignment; error when it cannot be known* Review feedback: fail properly in profiler when we are cloning code* Fix guest-profiler C API.* Review feedback: make private-code representation impossible in non-debugging-support builds.* Add TODO comment referencing issue for cloning only .text.* clang-format* Review feedback: add back Component::image_range.* Review feedback: error on registering profiling metadata when debug is enabled.* rustfmt* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

155ea7fc - Remove unsoundness of widening store borrows (#11481)

Thu, 21 Aug 2025 01:24:33 +0000

Remove unsoundness of widening store borrows (#11481)* Remove unsoundness of widening store borrowsThis commit removes preexisting unsoundness in Wasmtime where a`&mut StoreOpaque` borrow was "widened" into encompassing the limiter onthe `T` in `StoreInner`, for example, by using the self-pointerlocated in an instance or the store. This fix is done by threading`&mut StoreOpaque` as a parameter separately from a`StoreResourceLimiter`. This means that various callers now take a new`Option<&mut StoreResourceLimiter<'_>>` parameter in various locations.Closes #11409* Fix gc-less build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

d1397130 - Make const-expr evaluation `async` (#11468)

Wed, 20 Aug 2025 17:27:05 +0000

Make const-expr evaluation `async` (#11468)* Make const-expr evaluation `async`This commit is extracted from #11430 to accurately reflect howconst-expr evaluation is an async operation due to GC pauses that mayhappen. The changes in this commit are:* Const-expr evaluation is, at its core, now an `async` function.* To leverage this new `async`-ness all internal operations are switched from `*_maybe_async` to `*_async` meaning all the `*_maybe_async` methods can be removed.* Some libcalls using `*_maybe_async` are switch to using `*_async` plus the `block_on!` utility to help jettison more `*_maybe_async` methods.* Instance initialization is now an `async` function. This is temporarily handled with `block_on` during instance initialization to avoid propagating the `async`-ness further upwards. This `block_on` will get deleted in future refactorings.* Const-expr evaluation has been refactored slightly to enable having a fast path in global initialization which skips an `await` point entirely, achieving performance-parity in benchmarks prior to this commit.This ended up fixing a niche issue with GC where if a wasm execution wassuspended during `table.init`, for example, during a const-exprevaluation triggering a GC then if the wasm execution was cancelled itwould panic the host. This panic was because the GC operation returned`Result` but it was `unwrap`'d as part of the const-expr evaluationwhich can fail not only to invalid-ness but also due to "computation iscancelled" traps.* Fix configured build* Undo rebase mistake List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

aef5eeb5 - Refactor internals of table initialization and management (#11416)

Tue, 12 Aug 2025 22:32:11 +0000

Refactor internals of table initialization and management (#11416)* Refactor const-eval to use `Val`, not `ValRaw`This commit refactors the evaluation of constant expressions duringinstantiation for example to use `Val` instead of `ValRaw`. Previouslythe usage of `ValRaw` meant that wasm was disallowed from performing aGC during const evaluation, but currently constant expressions canindeed perform a GC. The goal of this commit is to lift this limitation.This is expected to be a minor slowdown for modules that hit this path,but most modules shouldn't hit this in a hot loop since LLVM doesn'tgenerate modules that use this branch of const eval.The usage of `Val` brings a number of benefits and refactoringsassociated with it:* Const-evaluation is generally safer than before since everything is higher-level.* GC types in const-eval were almost already using `Val` meaning that there's actually fewer conversions now.* Instantiation code was refactored to use `wasmtime::*`-API types instead of low-level VM types. This deduplicates a good deal and lifts complexity out of the raw VM bits.Another issue that this commit fixes is to change how tableinitialization is modeled internally in`vm::Instance::table_init_segment`. Previously this was done by removingthe tables from an instance to get a split borrow into the store and thetable. This is not valid though because if, during initialization, a GCis performed then the table is not present to find roots through thetable. This function is refactored to scope borrows to within a loopinstead of over a loop via various refactorings and such and usage ofhigher level APIs. This is again, like above, expected to pessimizeperformance but this is also not known to be a hot path for modules atthis time.* Remove the `TableElement` typeThis commit is a refactoring of how tables work within Wasmtime to avoidfunneling table elements through a `TableElement` enum internally.Instead methods are "exploded" to `grow_{gc_ref,func,cont}` which means,for example, funcrefs don't need a GcStore. The main motivation for thischange was to avoid the idiom where `TableElement` represents a cloned,but unrooted, GC reference.Prior to this commit there were a number of subtle bugs in the tablecode for Wasmtime where write barriers were forgotten on `table.init`,`table.set` (via the embedder API), and `table.grow`. While `table.fill`correctly handled the GC references it was awkward to get everythingelse working consistently so I opted to remove `TableElement` entirelyto make it more clear that `&VMGcRef` is ubiquitously used meaning thatthe write barriers, for example, are the same as other parts of theWasmtime codebase.This has a few extra tests for "make sure this doesn't leak" to ensurethat GC works correctly with new barriers in place.* Fix some lints and warnings* Fix wmemcheck build* Review comments* Optimize const eval and global initialization* Fix compile* Fix lints List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

def5998e - Remove `cranelift_entity::{Signed, Unsigned}` (#11400)

Thu, 07 Aug 2025 23:44:38 +0000

Remove `cranelift_entity::{Signed, Unsigned}` (#11400)Use `*::cast_{un,}signed` in the Rust standard library stabilized in1.87. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

686ea892 - Make `Val::to_raw` a safe function (#11319)

Thu, 24 Jul 2025 20:18:59 +0000

Make `Val::to_raw` a safe function (#11319)This commit updates Wasmtime's core `Val::to_raw` function a safefunction. This was previously marked as `unsafe` with documentation thatthe raw pointer could be invalid, but that's not a reason for thefunction itself to be `unsafe`. Usage of the returned value is still`unsafe`, but simply acquiring the value is not itself an unsafeoperation.This additionally marks a number of GC-related `from_raw` functions assafe. Wasmtime's GC is safe in the face of heap corruption, so it'smemory safe to pass in any 32-bit value. Documentation still indicatesthat panics are possible, however. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

35786823 - Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)

Wed, 23 Jul 2025 21:50:06 +0000

Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)* Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm`Slowly expanding this lint to more of the crate.prtest:full* Fix lints in custom module* Fix some lints with miri* Fix non-VM build* Fix arm windows List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

2bac6574 - Update the `log` dependency (#11197)

Mon, 07 Jul 2025 23:25:45 +0000

Update the `log` dependency (#11197)* Update the `log` dependencyThis enables getting warnings about formatting strings in the `log`crate directives which are then additionally fixed here as well.* Update dependency directive in `Cargo.toml` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.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/vm/const_expr.rs

aad93a48 - Crack down on mutability and ownership of `vm::Instance` (#10943)

Fri, 06 Jun 2025 15:59:57 +0000

Crack down on mutability and ownership of `vm::Instance` (#10943)* Crack down on mutability and ownership of `vm::Instance`This commit represents more effort to bring safety to `vm::Instance`and, eventually, `ComponentInstance`. This is specifically addressingtwo points of safety around `vm::Instance`:* Previously ownership of this was murky where `InstanceHandle` sort of represented ownership but sort of didn't either through the `InstanceHandle::clone` method. Now `InstanceHandle` has a destructor for instances and no longer has `clone`, so there's one exclusive owner of an instance.* Previously `&mut Instance` was liberally passed around, but this is not sound because certain fields cannot be mutated (e.g. runtime offset information). While not a perfect solution this PR switches to using `Pin<&mut Instance>` everywhere instead. This prevents safe access to `&mut Instance` and we hand-write accessors to individual fields. Notably we omit mutable access to the `runtime_info` field.This naturally involved a lot of refactoring internally, but notablythis started bringing up preexisting issues around how there arelocations in the codebase that simultaneously have `&mut Instance` and`&mut StoreOpaque` which is technically not sound due to being able toget back to the instance from the store. Some issues here were addressby passing around indices more often such as in instance initializationand const-expr evaluation.Note that all proxy methods on `InstanceHandle` are also all removed nowand there's now only two: `get` and `get_mut`. This reflects how`InstanceHandle` should in general no longer be used and instead`Instance` itself, and some pointer-to thereof, should be exclusivelyused.cc #10933* Fix stack-switching-less build* Fix wmemcheck build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.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/runtime/vm/const_expr.rs

fc3302a0 - Update spec test suite (#10611)

Fri, 18 Apr 2025 00:51:10 +0000

Update spec test suite (#10611)Now that wasm-tools is updated it's possible to run the latest versionagain. This notably required implementing the `extern.convert_any` and`any.convert_extern` instructions in a const-expression context. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.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/wasmtime/src/runtime/vm/const_expr.rs

07c71ab5 - Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions (#10560)

Thu, 10 Apr 2025 15:15:56 +0000

Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions (#10560)* Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functionsRather than forcing all callers to check for `GcHeapOutOfMemory`, trigger a GC,and then try again. This does force us to define `*_async` variations for whenasync is enabled, however; it's ultimately worth it.* cargo fmt* review feedback and fix tests* fix +runtime -gc build* more feedback and build cfg fixes* remove copy-paste assertion that doesn't apply to this method* move assertion into retry methods List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

956ca003 - `AnyRef::from_raw` needs to clone its GC ref (#10374)

Wed, 12 Mar 2025 02:03:25 +0000

`AnyRef::from_raw` needs to clone its GC ref (#10374)Like `ExternRef::from_raw` does.This is because while `to_raw` clones the GC ref, it also exposes it to Wasm,inserting it into the DRC collector's table, which effectively gives ownershipof that clone to Wasm. Then, if we don't clone in `from_raw`, when a GC istriggered, the DRC collector will see that Wasm isn't holding the ref aliveanymore and will decref (and perhaps even deallocate) it, which leaves the`AnyRef` we constructed via `from_raw` dangling.Fixes #10182 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.rs

cb235ecf - Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)

Fri, 14 Feb 2025 17:03:26 +0000

Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime (#10223)* Fix assertion in `PartialEq` for `RegisteredType` againIt is possible for two `WasmSubType`s to be equal to each other, as far as`derive(PartialEq)` is concerned, but still different from each other if theyare in different rec groups or even if they are at different indices within thesame rec group. The assertion mistakenly did not permit either of these,however.Fixes #9714* Canonicalize all types for runtime usage when creating `wasmtime::{Module,Component}`sRather than canonicalizing them on demand in functions like`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it inone place, up front, so that it is very unlikely we miss anything. Doing thisinvolves changing some things from `ModuleInternedTypeIndex`es to`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch ofuses of those things need to unwrap the appropriate kind of type index at usagesites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtimeuses usage will unwrap `VMSharedTypeIndex`es). And it additionally requiredimplementing the `TypeTrace` trait for a handful of things to unlock theprovided `canonicalize_for_runtime_usage` trait method for those things.All this machinery is required to avoid an assertion failure in the regressiontest introduced in the previous commit, which was triggered because we werefailing to canonicalize type indices inside `ExternType`s for runtime usage onsome code paths. We shouldn't have to play that kind of whack-a-mole in thefuture, thanks to this new approach.* Fix a warning in no-default-features builds* Fix another warning in weird cfg builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/const_expr.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/runtime/vm/const_expr.rs