Changes in runtime

7e0331c2 - Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)

Wed, 11 Feb 2026 23:00:00 +0000

Debugging: refactor stack frame cursor into frame handle abstraction. (#12566)* Debugging: refactor stack frame cursor into frame handle abstraction.This addresses some of the issues described #12486: we need the abilityto keep a handle to a stack frame as long as execution is frozen, andkeep multiple of these handles around, alongside the `Store`, withoutany handle directly holding a borrow of the store.The frame handles work by means of an "execution version" scheme: theidea is that whenever any execution resumes in a given store, allhandles to existing frames could be invalidated, but if no suchexecution occurs, all handles should still be valid. A tuple of(globally unique for process lifetime) store ID, and execution versionwithin that store, should be sufficient to uniquely identify anyfrozen-stack period during execution. This accomplishes cheap handleinvalidation without the need to track existing handles.This PR also implements a cache of parsed frame-table data. Previouslythis was lazily parsed by the cursor as it walked up a stack, but withmultiple handles hanging around, and with handles meant to be cheap tohold and clone, and with handles being invalidated eagerly, it makesmuch more sense to persist this parsed metadata at the `Store` level.(It cannot persist at the `Engine` level because PCs are local perstore.)* Re-bless disas tests (offsets in VMStoreContext changed).* Handle invalidation tests.* Review comments, and make API return `Result`s rather than panic'ing on stale handles.* Review feedback.* Doc-comment link fix.* Review feedback.* cfg-gate Activation method to `debug` feature only.* Fix unused-import warning in no-debug cfg.* Fix doc link (again, after rename from latest feedback). List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/vmcontext.rs

2811ee83 - feat(style,doc): added typos-cli workspace configuration (#12827)

Tue, 24 Mar 2026 22:00:00 +0000

feat(style,doc): added typos-cli workspace configuration (#12827)* init config values* more manual changes* typos write* revert certain changes* misused, tightened up hex encoding List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/traphandlers.rs

838ed2d0 - Enable `allow_attributes_without_reason` (#11195)

Mon, 07 Jul 2025 21:00:00 +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/traphandlers/coredump_enabled.rs

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

Wed, 03 Dec 2025 01:00: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/throw.rs

92f1829e - miri: add guest-debugging, including frame accesses. (#12575)

Thu, 12 Feb 2026 23:00:00 +0000

miri: add guest-debugging, including frame accesses. (#12575)* miri: add guest-debugging, including frame accesses.The fix to `vm_store_context` provenance in `record_unwind`/`unwind`is a little weird to me. I was seeing mut access to the`vm_store_context` via `store.vm_store_context_mut()` in`record_unwind` (before this diff) then access via the previouslysaved raw pointer in the `CallThreadState`, which was registered asinvalid and I believe is indeed invalid. This was only manifestingwhen setting `Config::guest_debug`, even without the frame-handleaccesses added here. I didn't dig into the exact diff in codegen orruntime behavior that caused this but in any case, accessing`vm_store_context` via these two different paths (with one mut)appears to be unsound in any case. The fix here is to set the unwindstate via the raw pointer in `CallThreadState` since that's the onlypath that the subsequent `unwind` has access to.Unrelated but useful: `ci/miri-provenance.test.sh` now accepts`MIRI_RUST_VERSION=+nightly` or whatnot, which is nice for runninglocally (I keep `stable` as my default toolchain).* Revert MIRI_RUST_VERSION in the CI script and add note about `rustup run` instead.* Add a bit more usage of debug API to Pulley provenance test.* Switch to using `Store`-derived `VMStoreContext` where available and re-deriving the raw pointer in `CallThreadState`.prtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/sys/unix/machports.rs/wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/traphandlers/backtrace.rs

e126fd1d - Fix panicking overflow when calculating table sizes (#13244)

Thu, 30 Apr 2026 15:00:00 +0000

Fix panicking overflow when calculating table sizes (#13244)Return an error instead of panicking in the same manner that OOM ishandled. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/table.rs

ad56ff98 - Implement unsafe intrinsics for compile-time builtins (#11825)

Fri, 17 Oct 2025 00:00:00 +0000

Implement unsafe intrinsics for compile-time builtins (#11825)* Implement unsafe intrinsics for compile-time builtinsThis commit adds the extremely unsafe`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasmbeing compiled is given access to special imports that correspond to direct,unchecked and unsandboxed, native load and store operations. These intrinsicsare intended to be used for implementing fast, inline-able versions of WASIinterfaces that are special-cased to a particular host embedding, for example.Compile-time builtins, as originally described in [theRFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up ofthree parts:1. A function inliner2. Unsafe intrinsics3. Component composition to encapsulate the usage of unsafe intrinsics in a safeinterfacePart (1) has been implemented in Wasmtime and Cranelift for a little whilenow (see `wasmtime::Config::compiler_inlining`). This commit is part (2). Afterthis commit lands, part (3) can be done with `wac` and `wasm-compose`, althoughfollow up work is required to make the developer experience nicer and moreintegrated into Wasmtime so that the APIs can look like those proposed in theRFC.* fill out some more docs* fix non component model builds* start filling out the doc example* Factor abi params/returns out; truncate/extend pointers* Compile unsafe intrinsics on winch as well* prtest:full* have the macro define the signature* ignore tests in MIRI because MIRI can't compile Wasm* juggle pointer provenance in `Store::data[_mut]`* add a test for store data provenance and also fix it* use `VmPtr` for the store data pointer* finish writing unsafe intrinsics example* fix up docs and rules around only accessing data from `T` in a `Store`* Only reserve space for the intrinsics' `VMFuncRef`s if they are in use* use dangling pointers instead of options* Rename `StoreInner::data` to `data_no_provenance` and fix some accesses to use the method accessors* Add comments about the provenance juggling inside `StoreInner::data[_mut]`* only compile intrinsics that are usedTurns out we don't need to add phases, we already have the info available to dothis.* fix duplicate symbol names List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/provenance.rs

facc9925 - Enable warnings if `async` is disabled (#10145)

Wed, 29 Jan 2025 18:00:00 +0000

Enable warnings if `async` is disabled (#10145)* Enable warnings if `async` is disabledContinuation of work in #10131.This required a number of organizational changes to help cut down on`#[cfg]`, notably lots of async-related pieces from `store.rs` havemoved to `store/async_.rs` to avoid having lots of conditional imports.Additionally this removes all of the `#[cfg]` annotations on thosemethods already.Additionally the signature of `AsyncCx::block_on` was updated to be abit more general to ideally remove the need for `Pin` but it ended upnot panning out quite just yet. In the future it should be possible toremove the need for `Pin` at callsites though.* Rebase conflicts List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/mpk/enabled.rs

e4e9cabe - Bump MSRV to Rust 1.91.0 (#12392)

Thu, 22 Jan 2026 18:00:00 +0000

Bump MSRV to Rust 1.91.0 (#12392)* Bump MSRV to Rust 1.91.0Coupled with today's release of Rust 1.93.0prtest:full* Fix warnings about cpuid being safe* Fix nightly build flags List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/mpk/pkru.rs

4bb429aa - Use `try_new` for `Arc` in `MmapMemory::new` (#12851)

Thu, 26 Mar 2026 22:00:00 +0000

Use `try_new` for `Arc` in `MmapMemory::new` (#12851) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/memory/mmap.rs