Changes in structref.rs

735bc9c0 - Implement `TryClone` for `GcLayout` (#12616)

Thu, 19 Feb 2026 16:23:46 +0000

Implement `TryClone` for `GcLayout` (#12616)And also make it so that cloning it doesn't actually require any allocations bywrapping the inner `GcStructLayout` in an `Arc`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.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/gc/enabled/structref.rs

9826719a - GC: replace ManuallyRooted with OwnedRooted. (#11514)

Tue, 26 Aug 2025 18:54:25 +0000

GC: replace ManuallyRooted with OwnedRooted. (#11514)* GC: replace ManuallyRooted with OwnedRooted.This implements the ideas from #11445: it replaces `ManuallyRooted`,which requires an explicit unroot action with a mut borrow of the store(making it impossible to implement in a standard `Drop` impl), with`OwnedRooted`, which holds an `Arc` only to a small auxiliary memoryallocation (an `Arc<()>`) and uses this externalized "liveness flag" toallow for a `Store`-less drop. These liveness flags are scanned during a"trim" pass, which happens both when new owned roots are created, andjust before a GC.This should greatly increase safety for host-side users of GC: itprovides a way to have a handle whose ownership works like any otherRust value, alive until dropped. It is still not quite as efficient asLIFO-scoped handles (by analogy, for the same reason thatindividually-freed RAII types are not as efficient as arena allocation),so those remain for efficiency-minded users that have a clear picture ofreference lifetimes.At some later time we may wish to use `OwnedRooted` exclusively in ourpublic APIs rather than `Rooted`, and we may wish to rename `Rooted` to`ScopedRooted`, but I haven't done either of those things yet.I opted to *replace* `ManuallyRooted` rather than add a third kind ofroot, after discussion with fitzgen. One implication of this is that theC API's `anyref` and `externref` types are now 24 or 20 bytes ratherthan 16 (because of the `Arc` pointer), and correspondingly the Valunion grew to that size. I *believe* this is an acceptable tradeoff, butI'm happy to put `ManuallyRooted` back if not.Fixes #11445.* Review feedback.* Fix for riscv32imac: loosen asserts on struct size slightly to allow for different padding.* C API: use a `*const ()` to pass the liveness-flag Arc through C.* Add some additional documentation warning about unrooting in the C API.* Fix size-of test on 32-bit platforms.* New amortized algorithm for root trimming.* core::cmp, not std::cmp* Always set high-water mark, even if eager.* Make val size-assert tolerant of padding bytes in crates/c-api/src/val.rs too. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.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/gc/enabled/structref.rs

4abb2133 - Deduplicate some more GC functions (#11480)

Thu, 21 Aug 2025 00:48:25 +0000

Deduplicate some more GC functions (#11480)Use the `async` version from sync API entrypoints to deduplicate theimplementation. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs

1d371af4 - Refactor exception objects to share more implementation with structs. (#11467)

Wed, 20 Aug 2025 18:37:13 +0000

Refactor exception objects to share more implementation with structs. (#11467)* Refactor exception objects to share more implementation with structs.This PR updates the implementation of Wasm exception objects to sharemore layout-computation code with structs, except for a single fixedtag slot. The former is simply a nice refactor, and the latter is inpreparation for full exception support, which will require accessingan exception's tag without knowing its layout dynamically at runtime.* Review feedback. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.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/gc/enabled/structref.rs

c6dddeaf - Minimize lazy allocation of the GC store (#11411)

Mon, 11 Aug 2025 20:47:20 +0000

Minimize lazy allocation of the GC store (#11411)* Minimize lazy allocation of the GC storeThis commit is an effort to minimize the number of entrypoints whichmight lazily allocate a GC store. The is currently done through`StoreOpaque::gc_store_mut` but this method is very commonly usedmeaning that there are many many places to audit for lazily allocating aGC store. The reason that this needs an audit is that lazy allocationis an async operation right now that must be on a fiber and is somethingI'm looking to fix as part of #11262.This commit performs a few refactorings to achieve this:* `gc_store_mut` is renamed to `ensure_gc_store`. This is intended to be an `async` function in the future and clearly demarcates where lazy allocation of a GC store is occurring.* `require_gc_store{,_mut}` is now added which is a pure accessor of the GC store with no lazy allocation. Most locations previously using `gc_store_mut` are updated to use this instead.Documentation is added to store methods to clearly indicate which onesare allocating and which ones should only be called in a context whereallocation should already have happened.* Fix configured build* Relax GC store restrictions in more places* Review comments on documentation* Move `ensure_gc_store` calls during instantiationInstead update `needs_gc_heap` with the tables that are added to amodule and rely on instantiation to create the GC heap.* Shuffle around some code* Fix CI and review comments* Add in a few more i31 cases for externref List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs

eaa4632e - Implement exception objects. (#11230)

Tue, 15 Jul 2025 17:15:35 +0000

Implement exception objects. (#11230)* WIP: Working exception objects* Clean build with gc disabled (`cargo check -p wasmtime --no-default-features --features runtime`).* Review feedback.* Stub out C-API support.* Fix Clippy complaints.* Fix dead-code warning in c-api build.* Actually fix 27->26 reserved bit rename and test.* Fix exnref doc-test.* fix fuzzing build* fix feature-flagging on Instance::id* Bless disas test diff due to reserved-bits change.* Review feedback. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.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/gc/enabled/structref.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/runtime/gc/enabled/structref.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/gc/enabled/structref.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.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/gc/enabled/structref.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/gc/enabled/structref.rs

9034e101 - Rely on `core::error::Error` (#9702)

Tue, 03 Dec 2024 18:27:28 +0000

Rely on `core::error::Error` (#9702)* Rely on `core::error::Error`With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` isavailable which means that in `no_std` mode the `Error` trait can beused. This has been integrated into `anyhow::Error` already upstream andmeans that we can remove our own local hacks such as the `Err2Anyhow` trait.This commit removes the `Err2Anyhow` trait and all usage, going back toidiomatic Rust error propagation and conversion even in the `no_std`world. This should make code more portable by default and remove someweird idioms we had for supporting this.prtest:full* Add some trusted vets* Audit object crate update* Disable backtraces on CI List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs

d2e3f7a5 - Improve a couple debug assertions for `{Array,Struct}Ref::from_cloned_gc_ref` (#9359)

Wed, 02 Oct 2024 19:58:36 +0000

Improve a couple debug assertions for `{Array,Struct}Ref::from_cloned_gc_ref` (#9359)Don't just assert that the given GC refs aren't `i31ref`s, but also that theyare of the correct type.Note that the other `from_cloned_gc_ref` methods (on, for example, `AnyRef`)already do their equivalents of these checks. Just these two were a littlelooser than they should have been. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs

c16414fb - Introduce the `wasmtime::EqRef` type (#9285)

Thu, 19 Sep 2024 19:48:54 +0000

Introduce the `wasmtime::EqRef` type (#9285)* Introduce the `wasmtime::EqRef` typeThis commit introduces the `wasmtime::EqRef` type, which corresponds to Wasm's`(ref eq)` type, and statically represents Wasm references that can be testedfor equality.* fix no-gc builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs

9c23d884 - Split GC type layout computation into a shared trait in `wasmtime_environ` (#9246)

Fri, 13 Sep 2024 20:50:05 +0000

Split GC type layout computation into a shared trait in `wasmtime_environ` (#9246)* Split GC type layout computation into a shared trait in `wasmtime_environ`This stuff was previously living in the `GcRuntime` trait, but it turns out that thecompiler will also need to know the layout of GC types, who'd have thunk it.* Fix disabled GC builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs

0c0153c1 - Enforce `clippy::clone_on_copy` for the workspace (#9025)

Sat, 27 Jul 2024 01:11:06 +0000

Enforce `clippy::clone_on_copy` for the workspace (#9025)* Derive `Copy` for `Val`* Fix `clippy::clone_on_copy` for the whole repo* Enforce `clippy::clone_on_copy` for the workspace* fix some more clippy::clone_on_copy that got missed List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/structref.rs