History log of /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs (Results 1 – 25 of 33)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2
# 43832481 27-Jan-2026 Zijie Zhao <[email protected]>

Fix `OwnedRooted<T>::wasm_ty_store` missing `i31ref` check (#12451)


# 49ca1380 27-Jan-2026 Nick Fitzgerald <[email protected]>

Force callers to handle allocation failure in `Slab` (#12450)

* Add `Vec::drain` method

* Force callers to handle allocation failure in `Slab`


# bc4582c3 27-Jan-2026 Alex Crichton <[email protected]>

Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our fl

Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our flags to pass
`-Dwarnings` to ensure that we have warning-free doc builds when all
features are enabled at least.

There were quite a lot of preexisting issues to fix, so this
additionally goes through and fixes all the warnings that cropped up.

* Update nightly toolchain again

prtest:full

* Update another nightly

* Fix a warning in generated code

show more ...


Revision tags: v41.0.1, v36.0.5, v40.0.3
# ab401d66 23-Jan-2026 Alex Crichton <[email protected]>

Move `wasmtime-slab` crate into `wasmtime-core` (#12407)

Consolidating core data structures in one location


Revision tags: v41.0.0, v36.0.4, v39.0.2, v40.0.2
# ff33e949 09-Jan-2026 Nick Fitzgerald <[email protected]>

Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)

We are trying to move to `format_err!` instead.


Revision tags: v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0
# 9826719a 26-Aug-2025 Chris Fallin <[email protected]>

GC: replace ManuallyRooted with OwnedRooted. (#11514)

* GC: replace ManuallyRooted with OwnedRooted.

This implements the ideas from #11445: it replaces `ManuallyRooted`,
which requires an explicit

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 memory
allocation (an `Arc<()>`) and uses this externalized "liveness flag" to
allow for a `Store`-less drop. These liveness flags are scanned during a
"trim" pass, which happens both when new owned roots are created, and
just before a GC.

This should greatly increase safety for host-side users of GC: it
provides a way to have a handle whose ownership works like any other
Rust value, alive until dropped. It is still not quite as efficient as
LIFO-scoped handles (by analogy, for the same reason that
individually-freed RAII types are not as efficient as arena allocation),
so those remain for efficiency-minded users that have a clear picture of
reference lifetimes.

At some later time we may wish to use `OwnedRooted` exclusively in our
public 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 of
root, after discussion with fitzgen. One implication of this is that the
C API's `anyref` and `externref` types are now 24 or 20 bytes rather
than 16 (because of the `Arc` pointer), and correspondingly the Val
union grew to that size. I *believe* this is an acceptable tradeoff, but
I'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.

show more ...


Revision tags: v36.0.2, v36.0.1, v36.0.0
# 8aefdcc0 18-Aug-2025 Alex Crichton <[email protected]>

Delete `StoreOpaque::traitobj_mut` (#11444)

* Delete `StoreOpaque::traitobj_mut`

This was a fundamentally unsound function because it is widening a
mutable borrow to encompass more than it original

Delete `StoreOpaque::traitobj_mut` (#11444)

* Delete `StoreOpaque::traitobj_mut`

This was a fundamentally unsound function because it is widening a
mutable borrow to encompass more than it originally contained. Removal
of its usage falls into a few buckets here:

* Many instances of `store.0.traitobj_mut()` were starting from a
`&mut StoreInner<T>`, going to `&mut StoreOpaque`, then going back to
`&mut dyn VMStore`. These are replaced with `store.0` as
`&mut StoreInner<T>` directly coerces into `&mut dyn VMStore`.

* Some fiber-related helpers were updated to take any store-opaque-thing
which encapsulates the ability to start/resume a borrow with a part of
the store, but you only get that part of the store during the fiber
itself. This means there's no widening necessary.

* Some methods previously taking `&mut StoreOpaque` are now
appropriately widened to `&mut dyn VMStore`.

This all enables full deletion of this function which prevents
accidentally ever tripping over its unsound-ness.

* Fix configured build

* Another fix for a configured build

* Fix a warning

* Don't hold `VMStore` live over await points

* Review comments

* Move `AsStoreOpaque` to `store.rs` and use it in GC

* Fix configured build

* Switch lint annotation

show more ...


# c6dddeaf 11-Aug-2025 Alex Crichton <[email protected]>

Minimize lazy allocation of the GC store (#11411)

* Minimize lazy allocation of the GC store

This commit is an effort to minimize the number of entrypoints which
might lazily allocate a GC store. T

Minimize lazy allocation of the GC store (#11411)

* Minimize lazy allocation of the GC store

This commit is an effort to minimize the number of entrypoints which
might lazily allocate a GC store. The is currently done through
`StoreOpaque::gc_store_mut` but this method is very commonly used
meaning that there are many many places to audit for lazily allocating a
GC store. The reason that this needs an audit is that lazy allocation
is an async operation right now that must be on a fiber and is something
I'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 ones
are allocating and which ones should only be called in a context where
allocation should already have happened.

* Fix configured build

* Relax GC store restrictions in more places

* Review comments on documentation

* Move `ensure_gc_store` calls during instantiation

Instead update `needs_gc_heap` with the tables that are added to a
module 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

show more ...


Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0
# 90ac295e 19-May-2025 Alex Crichton <[email protected]>

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...


Revision tags: v32.0.0
# 07c71ab5 10-Apr-2025 Nick Fitzgerald <[email protected]>

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

* Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions

Rather than forcing all callers to

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

* Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions

Rather than forcing all callers to check for `GcHeapOutOfMemory`, trigger a GC,
and then try again. This does force us to define `*_async` variations for when
async 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

show more ...


# a4700cb7 02-Apr-2025 Nick Fitzgerald <[email protected]>

Analyze whether a module requires a GC heap during its compilation (#10508)

* Analyze whether a module requires a GC heap during its compilation

And avoid forcing the allocation of a GC heap for mo

Analyze whether a module requires a GC heap during its compilation (#10508)

* Analyze whether a module requires a GC heap during its compilation

And avoid forcing the allocation of a GC heap for modules that will not use it.

Split out from https://github.com/bytecodealliance/wasmtime/issues/9350

* Simplify condition for allocating GC heap

show more ...


# b2e585cf 21-Mar-2025 Nick Fitzgerald <[email protected]>

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

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`, and
then 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 the
bottom half and that was our result.

But because our GC refs are non-zero, we don't need to extend to a `u64` to get
a sentinel for traps/panics; we can just use zero. That's what this commit does.

show more ...


Revision tags: v31.0.0
# 0a29578f 18-Mar-2025 Nick Fitzgerald <[email protected]>

Transitively dec-ref objects in the DRC collector (#10401)

* Transitively dec-ref objects in the DRC collector

Previously, the DRC collector only performed shallow reference counting where if
an ob

Transitively dec-ref objects in the DRC collector (#10401)

* Transitively dec-ref objects in the DRC collector

Previously, the DRC collector only performed shallow reference counting where if
an object's ref count was decremented and reached zero, then we would deallocate
that object, but we would not decrement the reference counts of any other object
that was referenced by it. This commit changes that, so that now we will
decrement the reference counts of other objects referenced by an object that is
being deallocated.

This requires some method of tracing an object's outgoing edges. To avoid
needing to keep around and dispatch upon type-specific information about which
struct fields are GC references, for example, we instead pack all GC references
at the start of the object, just after its header. We additionally keep a count
of how many GC references an object has in its header. This allows us to create
a slice of any object's GC references, and we can uniformly trace any GC
object's outgoing edges. We don't need to reflect on the GC object's actual
type.

A final detail: the DRC collector was previously storing the object size in the
common GC header's reserved bits. It now stores the number of GC refs there
instead, and the object size is stored in its own field in the DRC-specific
header, next to the ref count. This is nice because, since we are making the DRC
header larger anyways, it raises the DRC collector's implementation limit on
object size from `u27::MAX` to `u32::MAX`.

Fixes #9701

* update disas tests

* Remove newly-added debug-assert that isn't true in certain edge cases

Sometimes we need to deallocate uninitialized objects when initializing their
fields fails, and this assertion trips.

* fix some tests by returning an error of the correct kind of trap

rather than a generic anyhow error

* fix tracing GC refs on big-endian architectures

We can't cast to a slice, we need to do conversion from little-endian bytes.

show more ...


# e902e16c 12-Mar-2025 Nick Fitzgerald <[email protected]>

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 dance
where they get the raw representation of the GC ref

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 dance
where they get the raw representation of the GC ref before giving up ownership
of it to the `expose_gc_ref_to_wasm` call, and then do something with the raw GC
ref (like return it to Wasm or whatever).

This small refactoring boxes up that dance inside `expose_gc_ref_to_wasm` so
that callers don't have to do it themselves anymore. Makes things that much more
concise and harder to mess up.

show more ...


Revision tags: v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0, v27.0.0
# 8818b251 05-Nov-2024 Nick Fitzgerald <[email protected]>

Refactor `vm::Instance` for better `Store` safety (#9565)

* Refactor `vm::Instance` for better `Store` safety

At various times, for example in libcalls, we need to go from a raw `vmctx`
pointer tha

Refactor `vm::Instance` for better `Store` safety (#9565)

* Refactor `vm::Instance` for better `Store` safety

At various times, for example in libcalls, we need to go from a raw `vmctx`
pointer that Wasm gave us to both an `&mut Instance` and an `&mut
Store{Opaque,Context}`. This is a pretty fundamental unsafe aspect of
implementing a language runtimne in Rust, but we can tighten things up a bit and
make them a little safer than they currently are. This commit is such an
attempt and is notably tackling the issue of creating multiple store borrows
after we have an instance borrow.

This commit makes the following changes:

* `Instance` doesn't expose a method to get the raw `*mut dyn VMStore` pointer
or otherwise create a store borrow.

* You cannot construct an `Instance` directly from a `vmctx` pointer.

* There is now an `InstanceAndStore` type that represents unique access to both
an `Instance` and a `Store`.

* You can (with `unsafe`) create an `InstanceAndStore` from a raw `vmctx`
pointer. This generally only happens inside a couple "bottlenecks", not all
throughout the codebase, like the shared plumbing code for libcalls.

* The `InstanceAndStore` can be unpacked into a mutable borrow of an `Instance`
and a mutable borrow of a `Store`. This unpacking takes holds a mutable borrow
of the original `InstanceAndStore`, so double borrows of the store are no
longer a concern, so long as you don't use `unsafe` to create new
`InstanceAndStore`s for the same `vmctx`.

* All `Instance` methods and functions that previously would unsafely turn the
`Instance`'s internal store pointer into a store borrow to perform some action
now take a store argument, and this store is threaded around as necessary.

Altogether, I feel that we've ended up with an architecture that is a safety
improvement over where we were previously, and will help us properly avoid Rust
UB.

For what its worth, I do not think this is the end state. I foresee at least two
additional follow ups that I unfortunately do not currently have time for:

1. Create `ComponentInstanceAndStore`, which is the same thing that this commit
did but for components. I started on this but ran out of fuel while trying to
update macros for all the component shims and transcoders.

2. Stop dealing with `&mut vm::Table`s and `&mut vm::Global`s and all that in
the runtime. Instead just deal with indices, similar to how things are
structured in the host API level. This refactoring was not previously possible
due to (1) the `wasmtime` versus `wasmtime-runtime` crate split and (2) the lack
of `StoreOpaque`s threaded through the VM internals. The first blocker was
addressed a few months ago, this commit removes the second blocker. This will
still be a pretty large refactoring though, but I think ultimately will be worth
it.

* Fix wmemcheck build

* Remove `'static` from the `dyn VMStore` accessors; fix no-gc build

show more ...


Revision tags: v26.0.1, v25.0.3, v24.0.2, v26.0.0
# 12c20b22 10-Oct-2024 Nick Fitzgerald <[email protected]>

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 implement

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 and
converts it to an `externref` value. The `extern.convert_any` instruction takes
an `externref` value and converts it to an `anyref` value.

Rather than implementing wrapper objects -- for example an `struct
AnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reuse
the same representation converted references as their unconverted reference. For
example, `(any.convert_extern my_externref)` is identical to the original
`my_externref` value. This means that we don't actually emit any clif
instructions to implement these Wasm instructions; they are no-ops!

Wasm code remains none-the-wiser because it cannot directly test for the
difference between, for example, a `my_anyref` and the result of
`(extern.convert_any my_anyref)` because they are in two different type
hierarchies, so any direct `ref.test` would be invalid. The Wasm code would have
to convert one into the other's type hierarchy, at which point it doesn't know
whether 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

show more ...


Revision tags: v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1
# 818966f3 07-Oct-2024 Nick Fitzgerald <[email protected]>

Implement the `array.copy` Wasm GC instruction (#9389)

* Implement the `array.copy` Wasm GC instruction

This also involved fixing some `VMGcRef` initialization and GC barrier code for
globals. That

Implement the `array.copy` Wasm GC instruction (#9389)

* Implement the `array.copy` Wasm GC instruction

This also involved fixing some `VMGcRef` initialization and GC barrier code for
globals. That in turn involved making global initialization fallible, which
meant that it needed to be pulled out of `vmctx` initialization and put into
instance initialization.

Co-Authored-By: Alex Crichton <[email protected]>

* fix compile error due to code moving where a trait method was no longer in scope

* use the result of `MaybeUninit::write`

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...


Revision tags: v25.0.1, v25.0.0
# 128e6b8f 19-Sep-2024 Nick Fitzgerald <[email protected]>

Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)

* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions

* fix no-gc builds

Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)

* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions

* fix no-gc builds

* wrap const evaluation in `AutoAssertNoGc`

* add assertions that we access `VMGcRef`s in native-endian

* fix an endian mismatch bug between compiled wasm code and host code

show more ...


Revision tags: v24.0.0
# b2025ead 19-Aug-2024 Nick Fitzgerald <[email protected]>

Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)

This moves Wasmtime over from the old, regalloc-based stack maps system to the
new "user" stack maps system.

Removing t

Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)

This moves Wasmtime over from the old, regalloc-based stack maps system to the
new "user" stack maps system.

Removing the old regalloc-based stack maps system is left for follow-up work.

show more ...


Revision tags: v23.0.2
# 87817f38 29-Jul-2024 Alex Crichton <[email protected]>

Improve unsupported architecture errors in Wasmtime (#9039)

Don't rely purely on `compile_error!` which doesn't halt compilation.
Instead fill out some stubs which won't ever actually get compiled b

Improve unsupported architecture errors in Wasmtime (#9039)

Don't rely purely on `compile_error!` which doesn't halt compilation.
Instead fill out some stubs which won't ever actually get compiled but
prevent other compiler errors from cropping up.

show more ...


Revision tags: v23.0.1, v23.0.0
# 5393c2bf 15-Jul-2024 Bruce Mitchener <[email protected]>

Reduce typo count (#8951)


# 99b739fb 12-Jul-2024 Nick Fitzgerald <[email protected]>

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 of
the `VMGcRef` with the same lifetime, and becaus

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 of
the `VMGcRef` with the same lifetime, and because performing a GC requires a
mutable borrow of the store, there actually was no reason to differentiate
between checked and unchecked methods or require `AutoAssertNoGc` arguments.

Fixes https://github.com/bytecodealliance/wasmtime/issues/8940

show more ...


# 9459cf5e 12-Jul-2024 Nick Fitzgerald <[email protected]>

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

Fixes https://github.com/bytecodealliance/wasmtime/issues/8942


# f2e689cd 11-Jul-2024 Nick Fitzgerald <[email protected]>

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

* Introduce `wasmtime::StructRef` and allocating Wasm GC structs

This commit introduces the `wasmtime::StructRef` type and sup

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

* Introduce `wasmtime::StructRef` and allocating Wasm GC structs

This commit introduces the `wasmtime::StructRef` type and support for allocating
Wasm GC structs from the host. This commit does *not* add support for the
`struct.new` family of Wasm instructions; guests still cannot allocate Wasm GC
objects yet, but initial support should be pretty straightforward after this
commit 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 direction

There 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 allocating
is being kept alive for the duration that the allocation may live. This is
required for many reasons, but a basic example is getting a struct instance's
type from the embedder API: this does a type-index-to-`StructType` lookup and
conversion and if the type wasn't kept alive, then the type-index lookup will
result in what is logically a use-after-free bug. This won't be a problem for
Wasm guests (when we get around to implementing allocation for them) since their
module defines the type, the store holds onto its instances' modules, and the
allocation cannot outlive the store. For the host, we need another method of
keeping the object's type alive, since it might be that the host defined the
type and there is no module that also defined it, let alone such a module that
is being kept alive in the store.

The solution to the struct-type-lifetime problem that this commit implements for
hosts is for the store to hold a hash set of `RegisteredType`s specifically for
objects which were allocated via the embedder API. But we also don't want to do
a 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 and
a store id. All `StructRef` allocation methods require a `StructRefPre`
argument, which does a fast store id check, rather than a whole hash table
insertion.

I opted to require `StructRefPre` in all allocation cases -- even though this
has the downside of always forcing callers to create one before they allocate,
even if they are only allocating a single object -- because of two
reasons. First, this avoids needing to define duplicate methods, with and
without a `StructRefPre` argument. Second, this avoids a performance footgun in
the API where users don't realize that they *can* avoid extra work by creating a
single `StructRefPre` and then using it multiple times. Anecdotally, I've heard
multiple people complain about instantiation being slower than advertised but it
turns out they weren't using `InstancePre`, and I'd like to avoid that situation
for 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 code

And 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

show more ...


# b8872ed5 08-Jul-2024 Nick Fitzgerald <[email protected]>

Wasmtime: Pop GC LIFO roots even when there is no GC heap (#8899)

* Wasmtime: Pop GC LIFO roots even when there is no GC heap

We can create and root `i31ref`s without ever allocating a GC heap for

Wasmtime: Pop GC LIFO roots even when there is no GC heap (#8899)

* Wasmtime: Pop GC LIFO roots even when there is no GC heap

We can create and root `i31ref`s without ever allocating a GC heap for the
store, so we can't guard popping LIFO roots on the presence of a GC heap or else
we risk unbounded growth of the LIFO root set.

* Fix build with the gc feature disabled

show more ...


12