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

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

Make table growth a true `async fn` (#11442)

* Make table growth a true `async fn`

Upon further refactoring and thinking about #11430 I've realized that we
might be able to sidestep `T: Send` on th

Make table growth a true `async fn` (#11442)

* Make table growth a true `async fn`

Upon further refactoring and thinking about #11430 I've realized that we
might be able to sidestep `T: Send` on the store entirely which would be
quite the boon if it can be pulled off. The realization I had is that
the main reason for this was `&mut dyn VMStore` on the stack, but that
itself is actually a bug in Wasmtime (#11178) and shouldn't be done.
The functions which have this on the stack should actually ONLY have the
resource limiter, if configured. This means that while the
`ResourceLimiter{,Async}` traits need a `Send` supertrait that's
relatively easy to add without much impact. My hunch is that plumbing
this through to the end will enable all the benefits of #11430 without
requiring adding `T: Send` to the store.

This commit starts out on this journey by making table growth a true
`async fn`. A new internal type is added to represent a store's limiter
which is plumbed to growth functions. This represents a hierarchy of
borrows that look like:

* `StoreInner<T>`
* `StoreResourceLimiter<'_>`
* `StoreOpaque`
* `Pin<&mut Instance>`
* `&mut vm::Table`

This notably, safely, allows operating on `vm::Table` with a
`StoreResourceLimiter` at the same time. This is exactly what's needed
and prevents needing to have `&mut dyn VMStore`, the previous argument,
on the stack.

This refactoring cleans up `unsafe` blocks in table growth right
now which manually uses raw pointers to work around the borrow checker.
No more now!

I'll note as well that this is just an incremental step. What I plan on
doing next is handling other locations like memory growth, memory
allocation, and table allocation. Each of those will require further
refactorings to ensure that things like GC are correctly accounted for
so they're going to be split into separate PRs. Functionally though this
PR should have no impact other than a fiber is no longer required for
`Table::grow_async`.

* Remove #[cfg] gate

show more ...

Add `#[inline]` to some small functions (#11235)

This adds `#[inline]` to some functions which are otherwise not
available for cross-crate inlining. These functions started being more
heavily used a

Add `#[inline]` to some small functions (#11235)

This adds `#[inline]` to some functions which are otherwise not
available for cross-crate inlining. These functions started being more
heavily used after historical refactorings such as #10877 so this helps
benchmarks which access linear memory in host functions, for example.

show more ...

Crack down on mutability and ownership of `vm::Instance` (#10943)

* Crack down on mutability and ownership of `vm::Instance`

This commit represents more effort to bring safety to `vm::Instance`
and

Crack down on mutability and ownership of `vm::Instance` (#10943)

* Crack down on mutability and ownership of `vm::Instance`

This commit represents more effort to bring safety to `vm::Instance`
and, eventually, `ComponentInstance`. This is specifically addressing
two points of safety around `vm::Instance`:

* Previously ownership of this was murky where `InstanceHandle` sort of
represented ownership but sort of didn't either through the
`InstanceHandle::clone` method. Now `InstanceHandle` has a destructor
for instances and no longer has `clone`, so there's one exclusive
owner of an instance.

* Previously `&mut Instance` was liberally passed around, but this is
not sound because certain fields cannot be mutated (e.g. runtime
offset information). While not a perfect solution this PR switches to
using `Pin<&mut Instance>` everywhere instead. This prevents safe
access to `&mut Instance` and we hand-write accessors to individual
fields. Notably we omit mutable access to the `runtime_info` field.

This naturally involved a lot of refactoring internally, but notably
this started bringing up preexisting issues around how there are
locations in the codebase that simultaneously have `&mut Instance` and
`&mut StoreOpaque` which is technically not sound due to being able to
get back to the instance from the store. Some issues here were address
by passing around indices more often such as in instance initialization
and const-expr evaluation.

Note that all proxy methods on `InstanceHandle` are also all removed now
and there's now only two: `get` and `get_mut`. This reflects how
`InstanceHandle` should in general no longer be used and instead
`Instance` itself, and some pointer-to thereof, should be exclusively
used.

cc #10933

* Fix stack-switching-less build

* Fix wmemcheck build

show more ...

Start reducing unsafety of `ComponentInstance` (#10934)

Work recently in the wasip3-prototyping repository has focused on
reducing the amount of `unsafe` code and improving internal abstractions
to

Start reducing unsafety of `ComponentInstance` (#10934)

Work recently in the wasip3-prototyping repository has focused on
reducing the amount of `unsafe` code and improving internal abstractions
to facilitate this. One major thrust that's manifested in is the removal
of the usage of `*mut ComponentInstance` where possible and instead
using an index to safely borrow from the store to get the entire
instance. This commit does not fully realize this vision just yet but
lays some groundwork leading up to this.

This commit specifically removes the `*mut ComponentInstance` pointers
in lift/lower contexts in favor of directly storing a
`wasmtime::component::Instance`. When the raw `ComponentInstance` is
needed it's acquired from the `StoreOpaque` in a safe fashion that
borrows the entire store for the duration of the returned borrow. This
in turn required pushing instances into the store earlier during
instantiation because during instantiation an instance could call out to
host APIs which do lifts/lowers.

There's still more work to be done to plumb this fully into libcalls and
host function invocations but I wanted to upstream the wasip3 work
piecemeal a chunk at a time.

show more ...

Change component/instance maps to `PrimaryMap` (#10916)

* Change component/instance maps to `PrimaryMap`

This switches to using typed keys for these maps to be more idiomatic
with the rest of Wasmt

Change component/instance maps to `PrimaryMap` (#10916)

* Change component/instance maps to `PrimaryMap`

This switches to using typed keys for these maps to be more idiomatic
with the rest of Wasmtime and this has the additional benefit of
compressing indices to 32-bits instead of the previous
pointer-sized-bits.

* Fix an unused import

show more ...

Remove `Stored<T>` (#10917)

Prior refactorings have removed the need for this abstraction, so delete
it entirely (yay!).

Remove Stored from wasmtime::Instance (#10909)

* Remove the "export cache" on instances

This is now a relic of the past now that conversion from the internal
to external representation of Wasmtime

Remove Stored from wasmtime::Instance (#10909)

* Remove the "export cache" on instances

This is now a relic of the past now that conversion from the internal
to external representation of Wasmtime items is free. This is
effectively dead code that is no longer needed.

* Remove `Stored` from `wasmtime::Instance`

Powered by all previous commits this is a near-trivial change where an
`Instance` is now more-or-less "just" an `InstanceId`. Additionally the
`host_state: Box<dyn Any>` is no longer needed within `vm::Instance` so
that was removed as well.

show more ...

Update the definition of `wasmtime::Table` (#10903)

This commit is similar to a prior commit modifying memories which
refactors the internals of `wasmtime::Table` to not longer use a
`Stored` index.

Update the definition of `wasmtime::Table` (#10903)

This commit is similar to a prior commit modifying memories which
refactors the internals of `wasmtime::Table` to not longer use a
`Stored` index. Instead a `StoreInstanceId` and a `DefinedTableIndex` is
used instead. This enables construction of external-facing types to be
trivial and zero-cost.

This additionally notably fixes an issue where triggering a GC in a
store would unconditionally create a `Table`, pushing onto an internal
vector in the store. This then would never be deallocated because the
internal table lived as long as the `Store`. In effect this meant that
triggering a GC would end up leaking memory by pushing more items onto
internal `Store` table. This is fixed through this commit because
creating a `wasmtime::Table` is now "free" and no longer requires any
allocations.

show more ...

Refactor the representation of `Func` (#10897)

* Refactor the representation of `Func`

This commit rewrites the internals of `wasmtime::Func`. The `Stored`
type is no longer used meaning that it's

Refactor the representation of `Func` (#10897)

* Refactor the representation of `Func`

This commit rewrites the internals of `wasmtime::Func`. The `Stored`
type is no longer used meaning that it's now free to create a
`wasmtime::Func` at any time. It is effectively a store-tagged
`NonNull<VMFuncRef>`. This required a few internal changes to how
functions are passed around:

* Previously the insertion of a `wasm_call`-less `VMFuncRef` was
deferred until the raw pointer was loaded. Now the insertion happens
immediately as soon as the function is placed within a store. This is
done to ensure that a `Func` corresponds to one exact `VMFuncRef` and
that's it, and lazily filled in versions within the store are still
lazily filled in but they're more eagerly allocated. This isn't
expected to have much of an impact perf-wise since all these lazily
allocated functions were already almost guaranteed to get lazily
allocated anyway.

* Filling in "holes" in `VMFuncRef`, notably the `wasm_call` field, no
longer happens lazily when the `VMFuncRef` is demanded. Instead during
instantiation a pass is made to fill in holes with the new module
being instantiated (after registration). Additionally when a
lazily-allocated `VMFuncRef` is created the module registry is checked
immediately. This means that all store-local `VMFuncRef` values are
either filled in immediately or filled in during instantiation. This
notably means that the previous logic in `Func::vmimport` is now
"just" an `.unwrap()` with a lot of comments saying why the unwrap
shouldn't panic.

* To implement this commit a previous optimization for the `Func` API was
removed as well, namely `Func::call` will become slower after this
commit. The `Func::call` API is a dynamically-typed API which requires
run-time type-checking of arguments. Previously a `FuncType` was loaded
into a cache once-per-`Func` which helped amortize the cost of using
`Func::call` repeatedly. Now, though, there's no natural place to put
such a cache since `Func` no longer has dedicated storage within a
`Store`. Historically this optimization was added for the C API before
the `*_call_unchecked` APIs existed, but nowadays the `*_call_unchecked`
APIs should suffice for performance-critical applications where needed.
In the future it might also be possible to have a hash map in the
`Store` of a `VMSharedTypeIndex` to `FuncType` which is lazily populated
based on calls to `Func::call`, but that feels a bit overkill nowadays
for a possibly rarely-used map.

* The no-longer-necessary `RootedHostFunc` type is now gone as its
unsafety and various contracts are subsumed by other preexisting
`unsafe` blocks.

* The specific drop order between `StoreOpaque::store_data` and
`StoreOpaque::rooted_host_funcs` is removed. The `rooted_host_funcs`
field now lives in the `func_refs` field and the `FuncKind` type,
where the destructors came from before, is no more.

* The `func_refs` field has grown storage locations for a variety of
"keep this thing alive as long as the store" related to functions and
such.

Closes #10868

* Remove mutability from locations that no longer need it

* Update crates/wasmtime/src/runtime/func.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

* Update crates/wasmtime/src/runtime/store/func_refs.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Refactor globals to no longer use `Stored` (#10902)

This commit refactors the `wasmtime::Global` to avoid the usage of
`Stored<T>` internally. This makes conversion from internal global state
to ext

Refactor globals to no longer use `Stored` (#10902)

This commit refactors the `wasmtime::Global` to avoid the usage of
`Stored<T>` internally. This makes conversion from internal global state
to external global state a noop along the lines of previous commits. The
end goal is to remove `Stored` entirely and enable more pervasively using
external types internally within Wasmtime as well.

Globals were different than the prior iterations of memories, tags, and
tables. Globals have three different ways of defining them: wasm
instances, the host embedder, and component flags. Representing these
in all the various locations required a bit of finesse in how everything
is represented and stored at rest and such. In the end there's a small
amount of "type punning" in a few instance/vmctx fields related to
globals now since everything is squeezed into one slot. This is required
because the `VMGlobalImport` structure must have a size known to
wasm-compiled code and `wasmtime::Global` must have a known layout for C
code.

In the end while this is more code to manage globals my hope is that the
end result will be a net negative in terms of complexity by ensuring
that the embedder API is additionally suitable for use internally within
Wasmtime as well.

show more ...

Refactor `wasmtime::Tag`'s representation (#10901)

Removes the use of `Stored` to ensure that creating an external `Tag` is
a free operation with just some indices into store-internal data.

Add a new `ComponentInstanceId` type (#10896)

This is intended to be similar to `InstanceId`, but used for components.

Update the definition of `wasmtime::Memory` (#10877)

Powered by the previous commit this change updates the internal
implementation details of `wasmtime::Memory` to avoid the need for the
use of `St

Update the definition of `wasmtime::Memory` (#10877)

Powered by the previous commit this change updates the internal
implementation details of `wasmtime::Memory` to avoid the need for the
use of `Stored`. This means that converting from a Wasmtime-internal
representation of a memory to an external representation of a memory is
largely a noop and no longer requires an allocation. This is intended to
be more useful in the future to use the public types more pervasively
inside of Wasmtime itself, but for now this is mostly the scaffolding
necessary for such a change.

show more ...

Store an `InstanceId` in `vm::Instance` (#10872)

* Store an `InstanceId` in `vm::Instance`

This commit is the beginning of an effort to clean up `unsafe`-related
code about how we manage instances

Store an `InstanceId` in `vm::Instance` (#10872)

* Store an `InstanceId` in `vm::Instance`

This commit is the beginning of an effort to clean up `unsafe`-related
code about how we manage instances in the guts of Wasmtime. This doesn't
have any affect on the public API but it's will result eventually in
changes to the internals of types in the public API. This change is also
done in preparation for simplifying `Stored<T>` and how it works in
Wasmtime to avoid requiring allocations (aka pushing onto a `StoreData`
vector) when converting from Wasmtime's internal representation to the
external representation of tables, globals, memories, etc.

For now all this commit does is add `id: InstanceId` to the
`vm::Instance` structure. This led to some refactorings to ensure that
it's correctly listed by centralizing various methods to allocate an
instance into one helper method which manages this configuration.

* Review comments

show more ...

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

Exception and control tags (#10251)

* Tags

* Tag tests

* Tests

* Refer to tags issue

* Engine index

* Simplify

* Fix clippy warnings

Support platforms without 64-bit atomics (#10134)

* Support platforms without 64-bit atomics

This commit enables Wasmtime to build on platforms without 64-bit atomic
instructions, such as Rust's `r

Support platforms without 64-bit atomics (#10134)

* Support platforms without 64-bit atomics

This commit enables Wasmtime to build on platforms without 64-bit atomic
instructions, such as Rust's `riscv32imac-unknown-none-elf` target.
There are only two users of 64-bit atomics right now which are epochs
and allocation of `StoreId`. This commit adds `#[cfg]` to epoch-related
infrastructure in the runtime to turn that all of if 64-bit atomics
aren't available. The thinking is that epochs more-or-less don't work
without 64-bit atomics so it's easier to just remove them entirely.

Allocation of `StoreId` is trickier though because it's so core to
Wasmtime and it basically can't be removed. I've opted to change the
allocator to 32-bit indices instead of 64-bit indices. Note that
`StoreId` requires unique IDs to be allocated for safety which means
that while a 64-bit integer won't overflow for a few thousand years a
32-bit integer will overflow in a few hours from quickly creating
stores. The rough hope though is that embeddings on platforms like this
aren't churning through stores. Regardless if this condition is
triggered it'll result in a panic rather than unsoundness, so we
hopefully have at least that going for us.

Closes #8768

* Update component resources to not use `AtomicU64`

These aren't intended to be used in threaded contexts anyway and the use
of `AtomicXXX` is just to have interior mutability while still being
`Send` and `Sync`. Switch to using `AtomicU32` which is more portable.

* Use `RwLock<u64>` for `StoreId` instead.

* Fix compile

* Fix imports

show more ...

Enable `impl-trait-overcaptures` 2024 transition lint (#9965)

* Enable `impl-trait-overcaptures` 2024 transition lint

This lint detects cases where returning `impl Trait` will work
differently in 2

Enable `impl-trait-overcaptures` 2024 transition lint (#9965)

* Enable `impl-trait-overcaptures` 2024 transition lint

This lint detects cases where returning `impl Trait` will work
differently in 2024 than in the current 2021 edition. Ambiguities are
resolved with `use<..>` syntax stabilized in Rust 1.82.0 to mean the
same thing in both editions.

* Fix some more `impl Trait` returns

* Tighten bounds on settings `iter`

* Fix build on 1.82.0

* Fix another capture on MSRV

show more ...

Make module ids unique per-process, not per-engine (#8758)

* Make module ids unique per-process, not per-engine

Currently all instances of `wasmtime::Module` have a unique 64-bit id
embedded into t

Make module ids unique per-process, not per-engine (#8758)

* Make module ids unique per-process, not per-engine

Currently all instances of `wasmtime::Module` have a unique 64-bit id
embedded into them. This ID was originally only used for affinity in the
pooling allocator as a quick check of module equality. This use case
only required engine-local ids so the initial implementation had an ID
allocator per-engine.

Later, however, this id was reused for `wasmtime::ModuleExport` which
was intended to skip the string lookup for an export at runtime. This
also stored a module id but it did not store an engine identifier. This
meant that it's possible to mix these up and pass the wrong export to
the wrong engine. This behavior can lead to a runtime panic in Wasmtime.

This commit fixes this by making the module identifier be global
per-process instead of per-engine. This mirrors how store IDs are
allocated where they're per-process instead of per-engine. The same
logic for why store IDs are unlikely to be exhausted applies here too
where this 64-bit space of identifiers is unlikely to be exhausted.

* Fix warnings

* Fix tests

show more ...

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTF

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becoming
officially supported this should provide a better onboarding experience
where the fallback custom platform is used. This will cause linker
errors if the symbols aren't implemented and searching/googling should
lead back to our docs/repo (eventually, hopefully).

* Change Wasmtime's TLS state to a single pointer

This commit updates the management of TLS to rely on just a single
pointer rather than a pair of a pointer and a `bool`. Additionally
management of the TLS state is pushed into platform-specific modules to
enable different means of managing it, namely the "custom" platform now
has a C function required to implement TLS state for Wasmtime.

* Delay conversion to `Instant` in atomic intrinsics

The `Duration` type is available in `no_std` but the `Instant` type is
not. The intention is to only support the `threads` proposal if `std` is
active but to assist with this split push the `Duration` further into
Wasmtime to avoid using a type that can't be mentioned in `no_std`.

* Gate more parts of Wasmtime on the `profiling` feature

Move `serde_json` to an optional dependency and gate the guest profiler
entirely on the `profiling` feature.

* Refactor conversion to `anyhow::Error` in `wasmtime-environ`

Have a dedicated trait for consuming `self` in addition to a
`Result`-friendly trait.

* Gate `gimli` in Wasmtime on `addr2line`

Cut down the dependency list if `addr2line` isn't enabled since then
the dependency is not used. While here additionally lift the version
requirement for `addr2line` up to the workspace level.

* Update `bindgen!` to have `no_std`-compatible output

Pull most types from Wasmtime's `__internal` module as the source of
truth.

* Use an `Option` for `gc_store` instead of `OnceCell`

No need for synchronization here when mutability is already available in
the necessary contexts.

* Enable embedder-defined host feature detection

* Add `#![no_std]` support to the `wasmtime` crate

This commit enables compiling the `runtime`, `gc`, and `component-model`
features of the `wasmtime` crate on targets that do not have `std`. This
tags the crate as `#![no_std]` and then updates everything internally to
import from `core` or `alloc` and adapt for the various idioms. This
ended up requiring some relatively extensive changes, but nothing too
too bad in the grand scheme of things.

* Require `std` for the perfmap profiling agent

prtest:full

* Fix build on wasm

* Fix windows build

* Remove unused import

* Fix Windows/Unix build without `std` feature

* Fix some doc links

* Remove unused import

* Fix build of wasi-common in isolation

* Fix no_std build on macos

* Re-fix build

* Fix standalone build of wasmtime-cli-flags

* Resolve a merge conflict

* Review comments

* Remove unused import

show more ...

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate

* Rewrite uses of `wasmtime

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate

* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`

* Remove dep on `wasmtime-runtime` from `wasmtime-cli`

* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module

* Update labeler for merged crates

* Fix `publish verify`

prtest:full

show more ...

c-api: Remove allocations from `wasmtime_val_t` (#8451)

* c-api: Remove allocations from `wasmtime_val_t`

This commit redesigns how GC references work in the C API. previously
`wasmtime_{any,extern

c-api: Remove allocations from `wasmtime_val_t` (#8451)

* c-api: Remove allocations from `wasmtime_val_t`

This commit redesigns how GC references work in the C API. previously
`wasmtime_{any,extern}ref_t` were both opaque pointers in the C API
represented as a `Box`. Wasmtime did not, however, provide the ability
to deallocate just the `Box` part. This was intended to be handled with
unrooting APIs but unrooting requires a `wasmtime_context_t` parameter,
meaning that destructors of types in other languages don't have a
suitable means of managing the memory around the
`wasmtime_{any,extern}ref_t` which might lead to leaks.

This PR takes an alternate approach for the representation of these
types in the C API. Instead of being an opaque pointer they're now
actual structures with definitions in the header file. These structures
mirror the internals in Rust and Rust is tagged to ensure that changes
are reflected in the C API as well. This is similar to how
`wasmtime_func_t` matches `wasmtime::Func`. This enables embedders to
not need to worry about memory management of these values outside of the
manual rooting otherwise required.

The hope is that this will reduce the likelihood of memory leaks and
otherwise not make it any harder to manage references in the C API.

* Run clang-format

* Review comments

* Replace macros with inline functions

* Add explicit accessors/constructors for the C API

* Fix C example

* Fix doc link

* Fix some doc issues

prtest:full

* Fix doxygen links

show more ...

c-api: Tidy up some `wasmtime_func_t` usage (#8461)

* c-api: Tidy up some `wasmtime_func_t` usage

Try to avoid using a `transmute` in the implementation of the C API and
instead use a `union` like

c-api: Tidy up some `wasmtime_func_t` usage (#8461)

* c-api: Tidy up some `wasmtime_func_t` usage

Try to avoid using a `transmute` in the implementation of the C API and
instead use a `union` like is being done in #8451. Additionally add some
helper functions to the header to work with null funcref values instead
of only documenting the implementation.

* Try to fix doxygen

show more ...