Changes in externref.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/externref.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/externref.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/externref.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/externref.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/externref.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/gc/enabled/externref.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/externref.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/externref.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/externref.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/externref.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/externref.rs

b2e585cf - Avoid some unnecessary reduces and extends around GC libcalls (#10458)

Fri, 21 Mar 2025 23:54:53 +0000

Avoid some unnecessary reduces and extends around GC libcalls (#10458)We are logically returning a `VMGcRef` from these libcalls, which is a`NonZeroU32` under the covers. We were representing that value as a `u32`, andthen to represent traps and panics, we packed that into a `u64` and if the `u64`was negative that meant there was a trap/panic but otherwise we could unpack thebottom half and that was our result.But because our GC refs are non-zero, we don't need to extend to a `u64` to geta sentinel for traps/panics; we can just use zero. That's what this commit does. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs

e902e16c - Make `GcStore::expose_gc_ref_to_wasm` return the raw GC ref (#10375)

Wed, 12 Mar 2025 02:01:00 +0000

Make `GcStore::expose_gc_ref_to_wasm` return the raw GC ref (#10375)Every caller of `expose_gc_ref_to_wasm` except for one does this weird dancewhere they get the raw representation of the GC ref before giving up ownershipof it to the `expose_gc_ref_to_wasm` call, and then do something with the raw GCref (like return it to Wasm or whatever).This small refactoring boxes up that dance inside `expose_gc_ref_to_wasm` sothat callers don't have to do it themselves anymore. Makes things that much moreconcise and harder to mess up. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.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/externref.rs

12c20b22 - Implement the Wasm GC instructions for converting between `anyref` and `externref` (#9435)

Thu, 10 Oct 2024 14:41:22 +0000

Implement the Wasm GC instructions for converting between `anyref` and `externref` (#9435)* Implement the Wasm GC instructions for converting between `anyref` and `externref`This commit implements two instructions:1. `any.convert_extern`2. `extern.convert_any`These instructions are used to convert between `anyref` and `externref`values. The `any.convert_extern` instruction takes an `anyref` value andconverts it to an `externref` value. The `extern.convert_any` instruction takesan `externref` value and converts it to an `anyref` value.Rather than implementing wrapper objects -- for example an `structAnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reusethe same representation converted references as their unconverted reference. Forexample, `(any.convert_extern my_externref)` is identical to the original`my_externref` value. This means that we don't actually emit any clifinstructions to implement these Wasm instructions; they are no-ops!Wasm code remains none-the-wiser because it cannot directly test for thedifference between, for example, a `my_anyref` and the result of`(extern.convert_any my_anyref)` because they are in two different typehierarchies, so any direct `ref.test` would be invalid. The Wasm code would haveto convert one into the other's type hierarchy, at which point it doesn't knowwhether wrapping/unwrapping took place.We did need some changes at the host API and host API implementation levels,however:* We needed to relax the requirement that a `wasmtime::AnyRef` only wraps a `VMGcRef` that points to an object that is a subtype of `anyref` and similar for `wasmtime::ExternRef`.* We needed to make the `wasmtime::ExternRef::data[_mut]` methods return an option of their associated host data, since any `externref` resulting from `(extern.convert_any ...)` does not have any associated host data. (This change would have been required either way, even if we used wrapper objects.)* fix tests* fix wasmtime-environ tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs

99b739fb - Remove `unchecked_*` methods on `Rooted`s for getting `VMGcRef`s (#8948)

Fri, 12 Jul 2024 22:18:19 +0000

Remove `unchecked_*` methods on `Rooted`s for getting `VMGcRef`s (#8948)Because they take a shared borrow of the store and return a shared borrow ofthe `VMGcRef` with the same lifetime, and because performing a GC requires amutable borrow of the store, there actually was no reason to differentiatebetween checked and unchecked methods or require `AutoAssertNoGc` arguments.Fixes https://github.com/bytecodealliance/wasmtime/issues/8940 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs

9459cf5e - Deduplicate `WasmTy` implementations for GC-managed types (#8946)

Fri, 12 Jul 2024 20:36:07 +0000

Deduplicate `WasmTy` implementations for GC-managed types (#8946)Fixes https://github.com/bytecodealliance/wasmtime/issues/8942 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs

f2e689cd - Introduce `wasmtime::StructRef` and allocating Wasm GC structs (#8933)

Thu, 11 Jul 2024 22:14:56 +0000

Introduce `wasmtime::StructRef` and allocating Wasm GC structs (#8933)* Introduce `wasmtime::StructRef` and allocating Wasm GC structsThis commit introduces the `wasmtime::StructRef` type and support for allocatingWasm GC structs from the host. This commit does *not* add support for the`struct.new` family of Wasm instructions; guests still cannot allocate Wasm GCobjects yet, but initial support should be pretty straightforward after thiscommit lands.The `StructRef` type has everything you expect from other value types in the`wasmtime` crate:* A method to get its type or check whether it matches a given type* An implementation of `WasmTy` so that it can be used with `Func::wrap`-style APIs* The ability to upcast it into an `AnyRef` and to do checked downcasts in the opposite directionThere are, additionally, methods for getting, setting, and enumerating a`StructRef`'s fields.To allocate a `StructRef`, we need proof that the struct type we are allocatingis being kept alive for the duration that the allocation may live. This isrequired for many reasons, but a basic example is getting a struct instance'stype from the embedder API: this does a type-index-to-`StructType` lookup andconversion and if the type wasn't kept alive, then the type-index lookup willresult in what is logically a use-after-free bug. This won't be a problem forWasm guests (when we get around to implementing allocation for them) since theirmodule defines the type, the store holds onto its instances' modules, and theallocation cannot outlive the store. For the host, we need another method ofkeeping the object's type alive, since it might be that the host defined thetype and there is no module that also defined it, let alone such a module thatis being kept alive in the store.The solution to the struct-type-lifetime problem that this commit implements forhosts is for the store to hold a hash set of `RegisteredType`s specifically forobjects which were allocated via the embedder API. But we also don't want to doa hash lookup on every allocation, so we also implement a `StructRefPre` type. A`StructRefPre` is proof that the embedder has inserted a `StructType`'s inner`RegisteredType` into a store. Structurally, it is a pair of the struct type anda store id. All `StructRef` allocation methods require a `StructRefPre`argument, which does a fast store id check, rather than a whole hash tableinsertion.I opted to require `StructRefPre` in all allocation cases -- even though thishas the downside of always forcing callers to create one before they allocate,even if they are only allocating a single object -- because of tworeasons. First, this avoids needing to define duplicate methods, with andwithout a `StructRefPre` argument. Second, this avoids a performance footgun inthe API where users don't realize that they *can* avoid extra work by creating asingle `StructRefPre` and then using it multiple times. Anecdotally, I've heardmultiple people complain about instantiation being slower than advertised but itturns out they weren't using `InstancePre`, and I'd like to avoid that situationfor allocation if we can.* Move `allow(missing_docs)` up to `gc::disabled` module instead of each `impl`* Rename `cast` to `unchecked_cast`* fix `GcHeapOutOfMemory` error example in doc example* document additional error case for `StructRef::new`* Use `unpack` method instead of open-coding it* deallocate on failed initialization* Refactor field access methods to share more codeAnd define `fields()` in terms of `field()` rather than the other way around.* Add upcast methods from structref to anyref* Remove duplicate type checking and add clarifying comments about initializing vs writing fields* make the `PodValType` trait safe* fix benchmarks build* prtest:full* add miri ignores to new tests that call into wasm List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs

86b599ff - A handful of clean ups for `AnyRef` (#8931)

Wed, 10 Jul 2024 19:24:30 +0000

A handful of clean ups for `AnyRef` (#8931)Adding `ty`, `matches_ty`, etc... methods that we have for other kinds ofvalues.Cleaning up doc comments.Add some same-store asserts.Splitting this out from a larger PR to make review easier. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs

1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)

Fri, 14 Jun 2024 15:24:12 +0000

Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe use it basically everywhere and it is annoying to have to import.I also did an audit of existing `use` statements and removed the now-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/externref.rs