Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)

* Handle OOM in more places in the public API

A bunch of random places:

* Add: `Trap::try_new` to handle OOM

Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)

* Handle OOM in more places in the public API

A bunch of random places:

* Add: `Trap::try_new` to handle OOM while creating traps
* Use: `TryVec` inside `Func::call_impl_do_call` and `wasm_val_raw_storage` to
hold the args and rets
* Add: `Instance::try_exports` for iterating over an instance's exports while
handling OOM
* `Linker:try_get`, like `Linker::get` but handling OOM
* `Linker:try_get_by_import`, like `Linker::get_by_import` but handling OOM
* Use `try_new` to box things in `SharedMemory::new`
* Use `TryVec` instead of `Vec` in our dynamic tables

* Add OOM tests for most of Wasmtime's public API

Excludes component-, async-, and compilation-related APIs.

* address review feedback

* fix test compilation

* fix c-api

show more ...

Use `TryPrimaryMap` in an instance's `OwnedImports` (#12847)

Use `TryVec` in the store's `FuncRefs` structure (#12845)

Rename our OOM-handling `Vec` to `TryVec` (#12721)

* Rename our OOM-handling `Vec` to `TryVec`

* fix tests that got mangled by the LSP server

* fix more tests mangled by LSP

Handle OOM in `Linker::instantiate_pre` (#12683)

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

We currently do a store-wide state-change on all registered modules
when the "single stepping" flag c

Debugging: apply single-stepping patches to modules instantiated after setting changes. (#12663)

We currently do a store-wide state-change on all registered modules
when the "single stepping" flag changes, patching in or out all
breakpoints. However, this design didn't account for modules
registered with the store *after* single-stepping is enabled (and new
modules may be registered any time an instantiation occurs). In
particular this is problematic when a debugger, e.g., sets the
single-step flag right at the beginning of execution of a "host main
function" that calls Wasm, before the main instantiation occurs.

This PR threads through the breakpoint state in the registration path,
with the narrow waist at `ModuleRegistry::register` which is the only
place where modules are added to the `LoadedCode`.

show more ...

Debugging: add unique-within-store IDs for every entity. (#12645)

When building an introspection API for use by a debugger, we need a
way to expose *identity*: that is, to give some way of knowing t

Debugging: add unique-within-store IDs for every entity. (#12645)

When building an introspection API for use by a debugger, we need a
way to expose *identity*: that is, to give some way of knowing that a
given `Memory`, `Instance`, etc. is *this* one and not *that* one. Our
handle types variously have either `Eq` implementations or
e.g. `Module::same` for the ones that wrap an `Arc` under-the-covers;
but that's not enough to allow a debugger to e.g. build a hashmap for
whatever metadata that it might expose via whatever debugging
protocol.

For maximal generality and flexibility, we should expose the unique
IDs that already more-or-less exist: for instances, that is their
instance ID directly; for entities owned by instances, we can build a
`u64` with the instance ID in the upper 32 bits and the defined-index
in the lower 32 bits. IDs for all entities except modules are
unique-within-a-Store (and this is all that is needed); IDs for
modules happen to reuse the `CompiledModuleId` and so are
unique-within-an-Engine.

I've opted to name these `debug_index_within_store` to scope the
feature and intended use-case clearly, but if there's a desire, I
could easily rename them to simply `index`. I shied away from that
here because I didn't want to give a notion that these indices are
somehow canonical or correspond to some order or other.

show more ...

Refactor `String` usage in `wasmtime_environ::Module` (#12565)

* Refactor `String` usage in `wasmtime_environ::Module`

Do not hold regular `String`s; instead use our own OOM-handling
`wasmtime_core

Refactor `String` usage in `wasmtime_environ::Module` (#12565)

* Refactor `String` usage in `wasmtime_environ::Module`

Do not hold regular `String`s; instead use our own OOM-handling
`wasmtime_core::alloc::String` or, even better, an interned `Atom` from the
`StringPool`.

Also avoid `IndexMap`, as it doesn't handle OOMs.

* Use OOM-handling `IndexMap` in `wasmtime_environ::Module`

* review feedback

show more ...

Consolidate component-related store data (#12549)

Instead of having `#[cfg]` within `store.rs` move it all to
`component/store.rs` to cut down on `#[cfg]`. It's a bit awkward in some
places trying t

Consolidate component-related store data (#12549)

Instead of having `#[cfg]` within `store.rs` move it all to
`component/store.rs` to cut down on `#[cfg]`. It's a bit awkward in some
places trying to borrow a bunch of fields at once, but it's not the end
of the world.

show more ...

Remove need for explicit `Config::async_support` knob (#12371)

* Refactor component model host function definitions

Push the `async`-ness down one layer.

* Remove need for explicit `Config::async

Remove need for explicit `Config::async_support` knob (#12371)

* Refactor component model host function definitions

Push the `async`-ness down one layer.

* Remove need for explicit `Config::async_support` knob

This commit is an attempt to step towards reconciling "old async" and
"new async" in Wasmtime. The old async style is the original async
support in Wasmtime with `call_async`, `func_wrap_async`, etc, where the
main property is that the store is "locked" during an async operation.
Put another way, a store can only execute at most one async operation at
a time. This is in contrast to "new async" support in Wasmtime with the
component-model-async (WASIp3) support, where stores can have more than
one async operation in flight at once.

This commit does not fully reconcile these differences, but it does
remove one hurdle along the way: `Config::async_support`. Since the
beginning of Wasmtime this configuration knob has existed to explicitly
demarcate a config/engine/store as "this thing requires `async` stuff
internally." This has started to make less and less sense over time
where the line between sync and async has become more murky with WASIp3
where 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 many
load-bearing aspects of Wasmtime that rely on this `async_support` knob.
For example once epochs + yielding are enabled it's required that all
Wasm is executed on a fiber lest it hit an epoch and not know how to
yield. That means that this commit is not a simple removal of
`async_support` but instead a refactoring/rearchitecting of how async is
used internally within Wasmtime. The high-level ideas within Wasmtime
now 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 now
gone. All stores are equally capable of executing sync/async, and the
change now is that dynamically some stores will require that async is
used with certain configuration. Additionally all panicking conditions
around `async_support` have been converted to errors instead. All
relevant APIs already returned an error and things are murky enough now
that it's not necessarily trivial to get this right at the embedder
level. In the interest of avoiding panics all detected async mismatches
are now first-class `wasmtime::Error` values.

The end result of this commit is that `Config::async_support` is a
deprecated `#[doc(hidden)]` function that does nothing. While many
internal changes happened as well as having new tests for all this sort
of behavior this is not expected to have a great impact on external
consumers. In general a deletion of `async_support(true)` is in theory
all that's required. This is intended to make it easier to think about
async/sync/etc in the future with WASIp3 and eventually reconcile
`func_wrap_async` and `func_wrap_concurrent` for example. That's left
for future refactorings however.

prtest:full

* Review comments

* Fix CI failures

show more ...

Reduce duplication amongst `debug_*` helpers (#12386)

Deduplicate the check for `guest_debug`, validity checks, and conversion
from `Export` to `Extern`. No functional change here, just a
refactorin

Reduce duplication amongst `debug_*` helpers (#12386)

Deduplicate the check for `guest_debug`, validity checks, and conversion
from `Export` to `Extern`. No functional change here, just a
refactoring.

show more ...

Debugging: provide access to private (non-exported) entities. (#12367)

* Debugging: provide access to private (non-exported) entities.

A debugger will need to access all entities (globals, tables,

Debugging: provide access to private (non-exported) entities. (#12367)

* Debugging: provide access to private (non-exported) entities.

A debugger will need to access all entities (globals, tables, memories),
even those that are not exported, in order to provide a full debugging
experience: for example, a developer who has a debugger attached to a
Wasm component will expect to be able to see data in its memory.

Historically we have been very careful in Wasmtime to provide access to
Wasm instances' entities only as the Wasm type system allows -- that is,
only if they are exported. However, debugging is privileged -- in the
same way that a native host debugger has `ptrace` and can view
everything about the debuggee, we need to provide APIs for seeing
through the encapsulation boundary.

To ensure that this "violation of encapsulation" is scoped only to the
extent needed for the legitimate need (debugging), this API is
dynamically available only when `guest_debug` is configured true for a
given engine. Otherwise, the accessor returns `None`.

I opted not to provide a full introspection API that enumerates all of
the entities as the debugger should already have access to the debuggee
module and be able to enumerate the entities. Thus, the API only
provides a host-API handle when asking for an entity by index in a given
instance's index space.

* Review feedback.

* Fix tests on 32-bit build (where threads and thus shared memory are not supported)

show more ...

Refactor core wasm host entrypoints (#12366)

* Refactor core wasm host entrypoints

This commit refactors the internals of how guest functions call out to
the host. Previously Wasmtime had a split w

Refactor core wasm host entrypoints (#12366)

* Refactor core wasm host entrypoints

This commit refactors the internals of how guest functions call out to
the host. Previously Wasmtime had a split where `Func::new`-style
constructors used one entrypoint and `Func::wrap`-style entrypoints used
a different entrypoint. This was required long ago when we had an array
and native ABI calling convention, but nowadays this is no longer
required. This refactors things to have a single base-level signature
which is the narrow waist through which all other function entrypoints
go through. This enables having a single function handle all the things
like panicking, call hooks, etc, and everything further builds on top of
it.

This commit additionally pushes the async-ness of a function down even
further. Previously many `*_async` constructors would quickly delegate
to their non-async counterpart, but this is expected to more-or-less
become not the right way to do things as wasmtime moves into the
future. Historical refactorings related to GC, for example, have pushed
`async` further down within Wasmtime and this continues that trend.
There's no immediate benefit just yet, but this is hoped to make future
refactorings easier.

Along the way some minor API changes happened too:

* `*_unchecked` constructors now work with `MaybeUninit<ValRaw>` to
correctly model how some values may not be initialized.
* Some `*_async` functions picked up `T: Send` which should have in
theory been required before and are now compiler-required.
* Longstanding/old internal functions have been shuffled
around/refactored.

Finally, another eventual goal of this work is to share more between
core wasm and components in terms of implementation. Right now the
component host function entrypoints are quite different than the core
wasm ones and that ideally wouldn't endure forever.

* Fix c-api build

* Fix dead code

* Fix benchmarks build

* Review comments

show more ...

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

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

Debugging: allow frame cursor to visit all activations. (#12176)

* Debugging: allow frame cursor to visit all activations.

In the initial design for the `DebugFrameCursor`, I was concerned
about th

Debugging: allow frame cursor to visit all activations. (#12176)

* Debugging: allow frame cursor to visit all activations.

In the initial design for the `DebugFrameCursor`, I was concerned
about the effects of host async on the stability of visiting earlier
activations (see also the discussion of async combinators in #11896).
The basic hypothesized problem was that when Wasm calls host-code
calls Wasm, the sequence of activations on the stack is not even
stable between async polls; so any debugger hook, which is an async
function, should not be allowed to hold a frame cursor across a yield
point since it could become invalidated if the next poll stacks up the
activations differently.

In further conversations it's become clear that this is not actually a
possibility, for the simple reason that the inner re-entrant
activations into the same store take full ownership (mutably reborrow)
that store, and that mut reborrow becomes part of the future; so the
exact chain of activations will remain in the same sequence when
re-polled. Said another way, it is impossible at any given level of
async host-code to create *more than one* future that re-enters the
same store and somehow poll those in different orders at different
times. The worst that a host-code async combinator can do is drop the
future that re-enters the store. This drops and invalidates whatever
frames a cursor held over a yield might be referencing, but it *also*
drops the async invocation of the debugger hook itself, and due to
lifetimes the cursor cannot escape that hook, so everything is still
sound.

This PR thus updates the `DebugFrameCursor` to visit all
activations. I've generalized the backtrace code a bit to enable this,
and built an internal `StoreBacktrace` that is an iterator over all
activations associated with the store.

At the `DebugFrameCursor` (public API) level, the two basic choices
were to present a sentinel for host frame(s) explicitly and make all
Wasm-specific accessors return `Option<T>`, or skip over host
frames. I opted for the latter, with `move_to_parent()` returning an
enum value now that indicates whether it moved to a new activation.

A note regarding the *async* component ABI: once debugging is possible
within a `run_concurrent` environment, it will again be the case that
a single frame cursor should see only one activation, because
each (re)-entry into the store becomes a new task, if my understanding
is correct. At that time, we should build an API that lets the
debugger see the activation for each task separately. That's a simpler
model ultimately, and it will be nice when we move to it, but as long
as we have the sync component ABI with async host code and the ability
to stack activations as we do today, we need to provide the debugger
this visibility.

(Aside: why does the debugger *need* to see more than one activation?
In addition to presenting a weird and incoherent view of the world to
the user if we don't, it is also necessary to implement the
"next" (step-over) debugger action, because otherwise a call to a host
function that re-enters the store may lead to a state with fewer, but
completely disjoint, stack frames on the "one latest activation" from
which it's not possible to reason about whether we've left the
called-into function yet.)

* Review feedback.

* cargo fmt.

show more ...

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 implem

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 few
types that better encapsulate the distinction we want to enforce.
Basically, there is almost never a bare `CodeMemory`; they are always
wrapped in an `EngineCode` or `StoreCode`, the latter being a per-store
instance of the former. Accessors are moved to the relevant place so
that, for example, one cannot get a pointer to a Wasm function's body
without being in the context of a `Store` where the containing module
has been registered. The registry then returns a `ModuleWithCode` that
boxes up a `Module` reference and `StoreCode` together for cases where
we need both the metadata from the module and the raw code to derive
something.

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 host
functions, it breaks our expected performance characteristics to make
the function pointers store-specific. This is fine as long as the
Wasm-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 also
have to be substantially refactored if we wanted to do away with this
exception.

The per-`Store` module registry is substantially refactored in this PR.
I got rid of the modules-without-code distinction (the case where a
module only has trampolines and no defined functions still works fine),
and organized the BTreeMaps to key on start address rather than end
address, which I find a little more intuitive (one then queries with the
dual 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.

show more ...

Prevent using shared memories with `Memory` (#12022)

* Prevent using shared memories with `Memory`

This commit fixes a few issues where it was possible to represent a wasm
shared linear memory with

Prevent using shared memories with `Memory` (#12022)

* Prevent using shared memories with `Memory`

This commit fixes a few issues where it was possible to represent a wasm
shared linear memory with the `wasmtime::Memory` type. This is not sound
because `wasmtime::Memory` provides safe Rust access to the bytes where
that is not possible with wasm shared memories. Shared memories in Rust
must be represented by `SharedMemory`, not `wasmtime::Memory`.

Specifically this commit prevents two vectors of this happening:

1. `Memory::new` now requires that the memory type specified is
non-shared. Instead `SharedMemory::new` must be used instead.

2. Core dumps now skip over shared memories when iterating over all
memories in the store. Supporting shared memories is left to a future
feature request for now.

* CI fixes

show more ...

Another batch of dependency updates (#11832)

* Another batch of dependency updates

Bringing some deps in `Cargo.toml` up-to-date with their latest versions
along the same lines as #11820 to avoid d

Another batch of dependency updates (#11832)

* Another batch of dependency updates

Bringing some deps in `Cargo.toml` up-to-date with their latest versions
along the same lines as #11820 to avoid deps getting too stale/old.

Code-wise this updates `anyhow` which enables preexisting Clippy
warnings to check more code, so those warnings are fixed here as well.

prtest:full

* Run rustfmt

show more ...

Remove unsoundness of widening store borrows (#11481)

* Remove unsoundness of widening store borrows

This commit removes preexisting unsoundness in Wasmtime where a
`&mut StoreOpaque` borrow was "

Remove unsoundness of widening store borrows (#11481)

* Remove unsoundness of widening store borrows

This commit removes preexisting unsoundness in Wasmtime where a
`&mut StoreOpaque` borrow was "widened" into encompassing the limiter on
the `T` in `StoreInner<T>`, for example, by using the self-pointer
located 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

show more ...

Make table/memory creation async functions (#11470)

* Make core instance allocation an `async` function

This commit is a step in preparation for #11430, notably core instance
allocation, or `Store

Make table/memory creation async functions (#11470)

* Make core instance allocation an `async` function

This commit is a step in preparation for #11430, notably core instance
allocation, or `StoreOpaque::allocate_instance` is now an `async fn`.
This function does not actually use the `async`-ness just yet so it's a
noop from that point of view, but this propagates outwards to enough
locations that I wanted to split this off to make future changes more
digestable.

Notably some creation functions here such as making an `Instance`,
`Table`, or `Memory` are refactored internally to use this new `async`
function. Annotations of `assert_ready` or `one_poll` are used as
appropriate as well.

For reference this commit was benchmarked with our `instantiation.rs`
benchmark in the pooling allocator and shows no changes relative to the
original baseline from before-`async`-PRs.

* Make table/memory creation `async` functions

This commit is a large-ish refactor which is made possible by the many
previous refactorings to internals w.r.t. async-in-Wasmtime. The end
goal of this change is that table and memory allocation are both `async`
functions. Achieving this, however, required some refactoring to enable
it to work:

* To work with `Send` neither function can close over `dyn VMStore`.
This required changing their `Option<&mut dyn VMStore>` arugment to
`Option<&mut StoreResourceLimiter<'_>>`
* Somehow a `StoreResourceLimiter` needed to be acquired from an
`InstanceAllocationRequest`. Previously the store was stored here as
an unsafe raw pointer, but I've refactored this now so
`InstanceAllocationRequest` directly stores `&StoreOpaque` and
`Option<&mut StoreResourceLimiter>` meaning it's trivial to acquire
them. This additionally means no more `unsafe` access of the store
during instance allocation (yay!).
* Now-redundant fields of `InstanceAllocationRequest` were removed since
they can be safely inferred from `&StoreOpaque`. For example passing
around `&Tunables` is now all gone.
* Methods upwards from table/memory allocation to the
`InstanceAllocator` trait needed to be made `async`. This includes new
`#[async_trait]` methods for example.
* `StoreOpaque::ensure_gc_store` is now an `async` function. This
internally carries a new `unsafe` block carried over from before with
the raw point passed around in `InstanceAllocationRequest`. A future
PR will delete this `unsafe` block, it's just temporary.

I attempted a few times to split this PR up into separate commits but
everything is relatively intertwined here so this is the smallest
"atomic" unit I could manage to land these changes and refactorings.

* Shuffle `async-trait` dep

* Fix configured build

show more ...

Make const-expr evaluation `async` (#11468)

* Make const-expr evaluation `async`

This commit is extracted from #11430 to accurately reflect how
const-expr evaluation is an async operation due to GC

Make const-expr evaluation `async` (#11468)

* Make const-expr evaluation `async`

This commit is extracted from #11430 to accurately reflect how
const-expr evaluation is an async operation due to GC pauses that may
happen. 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 was
suspended during `table.init`, for example, during a const-expr
evaluation triggering a GC then if the wasm execution was cancelled it
would panic the host. This panic was because the GC operation returned
`Result` but it was `unwrap`'d as part of the const-expr evaluation
which can fail not only to invalid-ness but also due to "computation is
cancelled" traps.

* Fix configured build

* Undo rebase mistake

show more ...

Relax the `Send` bound on fiber creation (#11454)

* Relax the `Send` bound on fiber creation

This commit removes the need for `Send` for all usages of fiber-related
bits. The goal is that the futu

Relax the `Send` bound on fiber creation (#11454)

* Relax the `Send` bound on fiber creation

This commit removes the need for `Send` for all usages of fiber-related
bits. The goal is that the future returned from `async` functions is
`Send` if all the inputs are `Send`, but there's no actual need to
require that in the function signatures themselves. This property was
identified in upcoming work to make more internals of Wasmtime `async`
where `async` functions are going to be used to implement the
synchronous path through Wasmtime where `Send` isn't a bound today, nor
ideally do we want to have it there.

The way this commit works is:

* First `make_fiber` now has a `Send` bound which makes it sound. Before
#11444 it took `&mut dyn VMStore` which is never `Send` and the
refactoring there missed adding this bound. This change required a few
`Send` bounds in `concurrent.rs` where it's expected to have no
impact as everything there is basically already `Send`.

* Next `make_fiber_unchecked` is added which is the same as `make_fiber`
except without a `Send` bound. The `on_fiber` function is then updated
to use this `*_unchecked` variant. This means that fibers can now be
used with non-`Send` stores. Crucially though the structure of
internals in play means that future produced is still only `Send` if
`T: Send` meaning that there is no loss in safety.

* Next some `Send` bounds were dropped throughout async functions in
Wasmtime as a proof-of-concept to require these changes to `on_fiber`.
This means that these entrypoints into Wasmtime no longer require
`Send`, but still naturally require `Send` if the result future is
sent to various threads.

* Finally a new doctest is added to `Instance::new_async` with a
`compile_fail` example to ensure that this fails. This is
unfortunately a very brittle test because all we can assert is that
compilation failed, not why compilation failed. That means that this
is likely to regress over time, but it's the best we can do at this
time.

Note that the goal here is NOT to remove `Send` bounds throughout
Wasmtime. Many of them are still required, for example all the ones
related to `Linker`. The realization is that we can remove some of the
"edge" bounds on entrypoints where the resulting future can be
conditionally `Send` depending on `T` meaning we don't actually have to
write down any bounds ourselves.

This refactoring will enable future refactorings to have sync-and-async
functions use the same internals and neither entrypoint needs to have a
`Send` bound.

* Review comments

show more ...

Fix a typo in the bounds of `InstancePre::instantiate_async` (#11451)

The refactoring in #10760 mistakenly switched the input argument to not
be constrained with the same `T` as the store of the `In

Fix a typo in the bounds of `InstancePre::instantiate_async` (#11451)

The refactoring in #10760 mistakenly switched the input argument to not
be constrained with the same `T` as the store of the `InstancePre`
itself.

show more ...

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

Raise `unsafe_op_in_unsafe_fn` further in Wasmtime (#11322)

* Raise `unsafe_op_in_unsafe_fn` further in Wasmtime

Now it's at `wasmtime::runtime`, not just `wasmtime::runtime::vm`.

* Review comments