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

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

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

Deduplicate some more GC functions (#11480)

Use the `async` version from sync API entrypoints to deduplicate the
implementation.

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

Make `Val::to_raw` a safe function (#11319)

This commit updates Wasmtime's core `Val::to_raw` function a safe
function. This was previously marked as `unsafe` with documentation that
the raw pointer

Make `Val::to_raw` a safe function (#11319)

This commit updates Wasmtime's core `Val::to_raw` function a safe
function. This was previously marked as `unsafe` with documentation that
the raw pointer could be invalid, but that's not a reason for the
function itself to be `unsafe`. Usage of the returned value is still
`unsafe`, but simply acquiring the value is not itself an unsafe
operation.

This additionally marks a number of GC-related `from_raw` functions as
safe. Wasmtime's GC is safe in the face of heap corruption, so it's
memory safe to pass in any 32-bit value. Documentation still indicates
that panics are possible, however.

show more ...

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

This commit enables the `clippy::allow_attributes_without_reason` for
the `wasmtime` crate which previou

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

This commit enables the `clippy::allow_attributes_without_reason` for
the `wasmtime` crate which previously forcibly allowed it. The reason
this was allowed was that when the workspace was first migrated the
Wasmtime crate had too many instances that I was willing to fix. I've
now come back around and tried to fix everything.

In short: ideally delete `#[allow]`, otherwise use `#[expect]`,
otherwise use `#[allow]`.

prtest:full

* Adjust some directives

* Fix some warnings

* Fix stack switching size tests on unix

* Don't have a conditional `Drop` impl

* Force `testing_freelist` method to be used

Too lazy to write `#[cfg]`, but not too lazy to write a test.

show more ...

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

Add `T: 'static` to `Store<T>` (#10760)

* Add `T: 'static` to `Store<T>

Since the beginning the `T` type parameter on `Store<T>` has had no
bounds on it. This was intended for maximal flexibility i

Add `T: 'static` to `Store<T>` (#10760)

* Add `T: 'static` to `Store<T>

Since the beginning the `T` type parameter on `Store<T>` has had no
bounds on it. This was intended for maximal flexibility in terms of what
embedders place within a `Store<T>` and I've personally advocated that
we need to keep it this way. In the development of the WASIp3 work,
however, I've at least personally reached the conclusion that this is no
longer tenable and proceeding will require adding a `'static` bound to
data within a store.

Wasmtime today [already] carries unsafe `transmute`s to work around this
lack of `'static` bound, and while the number of `unsafe` parts is
relatively small right now we're still fundamentally lying to the
compiler about lifetime bounds internally. With the WASIp3 async work
this degree of "lying" has become even worse. Joel has written up some
examples [on Zulip] about how the Rust compiler is requiring `'static`
bounds in surprising ways. These patterns are cropping up quite
frequently in the WASIp3 work and it's becoming particularly onerous
maintaining all of the `unsafe` and ensuring that everything is in sync.

In the WASIp3 repository I've additionally [prototyped a change] which
would additionally practically require `T: 'static` in more locations.
This change is one I plan on landing in Wasmtime in the near future and
while its main motivations are for enabling WASIp3 work it is also a
much nicer system than what we have today, in my opinion.

Overall the cost of not having `T: 'static` on `Store<T>` is effectively
becoming quite costly, in particular with respect to WASIp3 work. This
is coupled with all known embedders already using `T: 'static` data
within a `Store<T>` so the expectation of the impact of this change is
not large. The main downside of this change as a result is that when and
where to place `'static` bounds is sort of a game of whack-a-mole with
the compiler. For example I changed `Store<T>` to require `'static`
here, but the rest of the change is basically "hit compile until rustc
says it's ok". There's not necessarily a huge amount of rhyme-or-reason
to where `'static` bounds crop up, which can be surprising or difficult
to work with for users.

In the end I feel that this change is necessary and one we can't shy
away from. If problems crop up we'll need to figure out how to thread
that needle at that time, but I'm coming around to thinking that
`T: 'static` is just a fundamental constraint we'll have to take on at
this time. Maybe a future version of Rust that fixes some of Joel's
examples (if they can be fixed, we're not sure of that) we could
consider relaxing this but that's left for future work.

[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611
[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072
[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158

* Remove a no-longer-necessary `unsafe` block

* Update test expectations

* Fix gc-disabled builds

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

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

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

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

Rely on `core::error::Error` (#9702)

* Rely on `core::error::Error`

With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` is
available which means that in `no_std` mode the `Error`

Rely on `core::error::Error` (#9702)

* Rely on `core::error::Error`

With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` is
available which means that in `no_std` mode the `Error` trait can be
used. This has been integrated into `anyhow::Error` already upstream and
means that we can remove our own local hacks such as the `Err2Anyhow` trait.

This commit removes the `Err2Anyhow` trait and all usage, going back to
idiomatic Rust error propagation and conversion even in the `no_std`
world. This should make code more portable by default and remove some
weird idioms we had for supporting this.

prtest:full

* Add some trusted vets

* Audit object crate update

* Disable backtraces on CI

show more ...

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

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

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

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

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

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

Adding `ty`, `matches_ty`, etc... methods that we have for other kinds of
values.

Cleaning up doc comments.

Add some same-store asserts.

Splitting this

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

Adding `ty`, `matches_ty`, etc... methods that we have for other kinds of
values.

Cleaning up doc comments.

Add some same-store asserts.

Splitting this out from a larger PR to make review easier.

show more ...

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

* Add `anyhow` stuff to our internal `wasmtime` crate prelude

We use it basically everywhere and it is annoying to have to import

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

* Add `anyhow` stuff to our internal `wasmtime` crate prelude

We use it basically everywhere and it is annoying to have to import.

I also did an audit of existing `use` statements and removed the now-redundant
ones and replaced one-off imports with usage of the prelude, so that the prelude
is available by default in more places.

* Fix `cargo doc`

show more ...

docs: Fix small typo in externref docs (#8724)

Remove the native ABI calling convention from Wasmtime (#8629)

* Remove the native ABI calling convention from Wasmtime

This commit proposes removing the "native abi" calling convention used
in Was

Remove the native ABI calling convention from Wasmtime (#8629)

* Remove the native ABI calling convention from Wasmtime

This commit proposes removing the "native abi" calling convention used
in Wasmtime. For background this ABI dates back to the origins of
Wasmtime. Originally Wasmtime only had `Func::call` and eventually I
added `TypedFunc` with `TypedFunc::call` and `Func::wrap` for a faster
path. At the time given the state of trampolines it was easiest to call
WebAssembly code directly without any trampolines using the native ABI
that wasm used at the time. This is the original source of the native
ABI and it's persisted over time under the assumption that it's faster
than the array ABI due to keeping arguments in registers rather than
spilling them to the stack.

Over time, however, this design decision of using the native ABI has not
aged well. Trampolines have changed quite a lot in the meantime and it's
no longer possible for the host to call wasm without a trampoline, for
example. Compilations nowadays maintain both native and array
trampolines for wasm functions in addition to host functions. There's a
large split between `Func::new` and `Func::wrap`. Overall, there's quite
a lot of weight that we're pulling for the design decision of using the
native ABI.

Functionally this hasn't ever really been the end of the world.
Trampolines aren't a known issue in terms of performance or code size.
There's no known faster way to invoke WebAssembly from the host (or
vice-versa). One major downside of this design, however, is that
`Func::new` requires Cranelift as a backend to exist. This is due to the
fact that it needs to synthesize various entries in the matrix of ABIs
we have that aren't available at any other time. While this is itself
not the worst of issues it means that the C API cannot be built without
a compiler because the C API does not have access to `Func::wrap`.

Overall I'd like to reevaluate given where Wasmtime is today whether it
makes sense to keep the native ABI trampolines. Sure they're supposed to
be fast, but are they really that much faster than the array-call ABI as
an alternative? This commit is intended to measure this.

This commit removes the native ABI calling convention entirely. For
example `VMFuncRef` is now one pointer smaller. All of `TypedFunc` now
uses `*mut ValRaw` for loads/stores rather than dealing with ABI
business. The benchmarks with this PR are:

* `sync/no-hook/core - host-to-wasm - typed - nop` - 5% faster
* `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower
* `sync/no-hook/core - wasm-to-host - typed - nop` - no change
* `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% faster

These numbers are a bit surprising as I would have suspected no change
in both "nop" benchmarks as well as both being slower in the
params-and-results benchmarks. Regardless it is apparent that this is
not a major change in terms of performance given Wasmtime's current
state. In general my hunch is that there are more expensive sources of
overhead than reads/writes from the stack when dealing with wasm values
(e.g. trap handling, store management, etc).

Overall this commit feels like a large simplification of what we
currently do in `TypedFunc`:

* The number of ABIs that Wasmtime deals with is reduced by one. ABIs
are pretty much always tricky and having fewer moving parts should
help improve the understandability of the system.
* All of the `WasmTy` trait methods and `TypedFunc` infrastructure is
simplified. Traits now work with simple `load`/`store` methods rather
than various other flavors of conversion.
* The multi-return-value handling of the native ABI is all gone now
which gave rise to significant complexity within Wasmtime's Cranelift
translation layer in addition to the `TypedFunc` backing traits.
* This aligns components and core wasm where components always use the
array ABI and now core wasm additionally will always use the array ABI
when communicating with the host.

I'll note that this still leaves a major ABI "complexity" with respect
to native functions do not have a wasm ABI function pointer until
they're "attached" to a `Store` with a `Module`. That's required to
avoid needing Cranelift for creating host functions and that property is
still true today. This is a bit simpler to understand though now that
`Func::new` and `Func::wrap` are treated uniformly rather than one being
special-cased.

* Fix miri unsafety

prtest:full

show more ...

wasmtime(gc): Add the `wasmtime::NoExtern` value type (#8550)

* wasmtime(gc): Add the `wasmtime::NoExtern` value type

* ignore miri for new tests that run wasm

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