Reuse Wasm linear memories code for GC heaps (#10503)

* Reuse code for Wasm linear memories for GC heaps

Instead of bespoke code paths and structures for Wasm GC, this commit makes it
so that we no

Reuse Wasm linear memories code for GC heaps (#10503)

* Reuse code for Wasm linear memories for GC heaps

Instead of bespoke code paths and structures for Wasm GC, this commit makes it
so that we now reuse VM structures like `VMMemoryDefinition` and bounds-checking
logic. Notably, we also reuse all the associated bounds-checking optimizations
and, when possible, virtual-memory techniques to completely elide them.

Furthermore, this commit adds support for growing GC heaps, reusing the
machinery for growing memories, and makes it so that GC heaps always start out
empty. This allows us to properly delay allocating the GC heap's storage until a
GC 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

show more ...

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

* Fix assertion in `PartialEq` for `RegisteredType` again

It is possible for two `

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

* Fix assertion in `PartialEq` for `RegisteredType` again

It is possible for two `WasmSubType`s to be equal to each other, as far as
`derive(PartialEq)` is concerned, but still different from each other if they
are in different rec groups or even if they are at different indices within the
same rec group. The assertion mistakenly did not permit either of these,
however.

Fixes #9714

* Canonicalize all types for runtime usage when creating `wasmtime::{Module,Component}`s

Rather than canonicalizing them on demand in functions like
`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it in
one place, up front, so that it is very unlikely we miss anything. Doing this
involves changing some things from `ModuleInternedTypeIndex`es to
`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch of
uses of those things need to unwrap the appropriate kind of type index at usage
sites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtime
uses usage will unwrap `VMSharedTypeIndex`es). And it additionally required
implementing the `TypeTrace` trait for a handful of things to unlock the
provided `canonicalize_for_runtime_usage` trait method for those things.

All this machinery is required to avoid an assertion failure in the regression
test introduced in the previous commit, which was triggered because we were
failing to canonicalize type indices inside `ExternType`s for runtime usage on
some code paths. We shouldn't have to play that kind of whack-a-mole in the
future, thanks to this new approach.

* Fix a warning in no-default-features builds

* Fix another warning in weird cfg builds

show more ...

Wasmtime: fix `PartialEq` implementation for `RegisteredType` (#10091)

We were incorrectly checking whether they were in the same rec
group (i.e. whether the two `RegisteredType`s had the same `RecG

Wasmtime: fix `PartialEq` implementation for `RegisteredType` (#10091)

We were incorrectly checking whether they were in the same rec
group (i.e. whether the two `RegisteredType`s had the same `RecGroupEntry`)
rather than whether they were actually the same type or not, even if they were
in the same rec group.

This fixes one of two issues reported in #9714

show more ...

Add support for initializing/getting/setting `funcref`s in GC structs from host APIs (#9454)

* Add support for initializing/getting/setting `funcref`s in GC structs from host APIs

We implemented su

Add support for initializing/getting/setting `funcref`s in GC structs from host APIs (#9454)

* Add support for initializing/getting/setting `funcref`s in GC structs from host APIs

We implemented support for `funcref`s in both Wasm and host APIs for arrays, but
somehow only implemented support for `funcref`s in structs for compiled Wasm
code, and mistakenly forgot about them for structs and host APIs (and things
that use host APIs, such as const expressions).

* fix clippy

show more ...

Enforce `uninlined_format_args` for the workspace (#9065)

* Enforce `uninlined_format_args` for the workspace

* fix: failing `Monolith Checks` job

* fix: formatting

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 ...