Reduce type complexity of `InstanceAllocator` async functions (#12887)

This is a follow-on to #12849 to try to simplify some of the resulting
signatures a bit. Notably the `Result<..., OutOfMemory>`

Reduce type complexity of `InstanceAllocator` async functions (#12887)

This is a follow-on to #12849 to try to simplify some of the resulting
signatures a bit. Notably the `Result<..., OutOfMemory>` is now packaged
up directly into the output future, so the functions still retain a sort
of "async trait" feel even though they're still incompatible with
`#[async_trait]` (and can't be defined with that anyway).

show more ...

Relax panics in async/futures to traps/errors (#12688)

* Relax panics in async/futures to traps/errors

This commit is an admittance that I don't believe we're going to get
to a point where we are c

Relax panics in async/futures to traps/errors (#12688)

* Relax panics in async/futures to traps/errors

This commit is an admittance that I don't believe we're going to get
to a point where we are confident enough in the fuzzing of
component-model-async such that we could confidently say we're
exercising the vast majority of possible panics. Development of
component-model-async has shown a steady trickle of panics over the
course of the development of the feature, and this trend has been
persistent over time as well.

An attempt was made in #12119 to add a fuzzer dedicated to async events
but that didn't actually find anything in development and it has missed
a number of panics present before and discovered after its introduction.
Overall I do not know how to improve the fuzzer to the point that it
would find pretty much all of the existing async-related panics over
time.

To help address this concern of the `concurrent.rs` implementation this
commit goes through and replaces things like `unwrap()`, `assert!`,
`panic!`, and `unreachable!` with an error-producing form. The benefit
of this is that a bug in the implementation is less likely to result in
a panic and instead just results in a non-spec-compliant trap. The
downside of doing this though is that it can become unclear what errors
are "first class traps", or expected to be guest reachable, and which
are expected to be bugs in Wasmtime. To help address this I've performed
a few refactorings here as well.

* Some traps previously present as error strings are now promoted to
using `Trap::Foo` instead. This has some refactoring of the Rust/C
side as well to make it easier to define new variants. Tests were
additionally added for any trap messages that weren't previously
tested as being reachable.

* A new `bail_bug!` macro was added (internally) for Wasmtime. This is
coupled with a concrete `WasmtimeBug` error type (exported as
`wasmtime::WasmtimeBug`). The intention is that `bail!` continues to
be "here's a string and I'm a bit too lazy to make a concrete error"
while `bail_bug!` indicates "this is a bug in wasmtime please report
this if you see it".

The rough vision is that if an error condition is reached, and the system
is not broken in such a way that panicking is required, then `bail_bug!`
can be used to indicate a bug in Wasmtime as opposed to panicking. This
reduces the real-world impact of hitting these scenarios by downgrading a
CVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not all
panics are able to be transitioned to this as some are load bearing from
a safety perspective or similar (or indicate something equally broken),
but the vast majority of cases are suitable for "return a trap, lock
down the store, and let destructors take care of everything else".

This change additionally has resulted in API changes for `FutureReader`
and `StreamReader`. For example creation of these types now returns a
`Result` for when the `ResourceTable` is full, for example, instead of
panicking.

* Fix CI build

* Translate `WasmtimeBug` to panics in debug mode

* Review comments

* Refactor some stream methods for fewer panics

show more ...

Move `StringPool` to `wasmtime-environ` (#12562)

* Move `StringPool` to `wasmtime-environ`

* Remove old location's `mod` declaration

* always implement TryClone for hashbrown::DefaultHashBuilder

Add a reusable `StringPool` for interning strings (#12536)

* Add a reusable `StringPool` for interning strings

And make sure it handles allocation failure.

* fix string pool tests

* Address revie

Add a reusable `StringPool` for interning strings (#12536)

* Add a reusable `StringPool` for interning strings

And make sure it handles allocation failure.

* fix string pool tests

* Address review feedback

* One more piece of review feedback that got missed

show more ...

Use `core::convert::Infallible` instead of our own `Uninhabited` type (#12115)

* Use `core::convert::Infallible` instead of our own `Uninhabited` type

I didn't realize that the standard library alr

Use `core::convert::Infallible` instead of our own `Uninhabited` type (#12115)

* Use `core::convert::Infallible` instead of our own `Uninhabited` type

I didn't realize that the standard library already had an uninhabited type
available for us to reuse.

* Actually remove the uninhabited module and its re-exports

show more ...

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.

This PR impl

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.

This PR implements ideas from the [recent RFC] to serve as the basis
for Wasm (guest) debugging: it adds a stackslot to each function
translated from Wasm, stores to replicate Wasm VM state in the
stackslot as the program runs, and metadata to describe the format of
that state and allow reading it out at runtime.

As an initial user of this state, this PR adds a basic "stack view"
API that, from host code that has been called from Wasm, can examine
Wasm frames currently on the stack and read out all of their locals
and stack slots.

Note in particular that this PR does not include breakpoints,
watchpoints, stepped execution, or any sort of user interface for any
of this; it is only a foundation.

This PR still has a few unsatisfying bits that I intend to address:

- The "stack view" performs some O(n) work when the view is initially
taken, computing some internal data per frame. This is forced by the
current design of `Backtrace`, which takes a closure and walks that
closure over stack frames eagerly (rather than work as an
iterator). It's got some impressive iterator-chain stuff going on
internally, so refactoring it to the latter approach might not
be *too* bad, but I haven't tackled it yet.

A O(1) stack view, that is, one that does work only for frames as
the host API is used to walk up the stack, is desirable because some
use-cases may want to quickly examine e.g. only the deepest
frame (say, running with a breakpoint condition that needs to read a
particular local's value after each step).

- It includes a new `Config::compiler_force_inlining()` option that is
used only for testing that we get the correct frames after
inlining. I couldn't get the existing flags to work on a Wasmtime
config level and suspect there may be an existing bug there; I will
try to split out a fix for it.

This PR renames the existing `debug` option to `native_debug`, to
distinguish it from the new approach.

[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44

* Update to new APIs on Cranelift side.

* Test update.

* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.

* Convert to iterator form.

* Fix path in native-debug tests (debug -> native_debug rename).

* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.

* Add missing assert.

* Use builtin knob for forcing intra-module inlining instead.

* Review feedback:

- Make StackView own the current frame rather than handing it out. This
prevents the current frame (`FrameView`) from walking away and hiding
somewhere it shouldn't, to be used unsoundly later.
- Assert no-GC during stack walk.

* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.

* Review feedback: avoid downcasting funcs twice.

* Add debug feature to `wasmtime` crate's defaults.

* Review feedback: u32s for local and stack indices in debug host API.

* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.

* Remove some `srcloc` plumbing in Wasm translator.

* Rename native-debug back to debug, and make the new thing "guest debugging".

* rustfmt in debugging test.

* fix disas test after guest-debug CLI option rename.

* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.

* Review feedback: update doc comment on `Config::guest_debug`.

* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.

* Review feedback: miscellaneous comments.

* Review comment: fix wording in safety conditions.

* revert wasi-common submodule update

* Properly root values in debug frame slots.

Fixes #11841.

* Fix non-`debug`-feature build.

* Review feedback: naming.

* Ignore tests that compile modules in miri.

show more ...

Add PoolingAllocatorMetrics (#11490)

This exposes some basic runtime metrics derived from the internal state
of a `PoolingInstanceAllocator`.

Two new atomics were added to PoolingInstanceAllocator:

Add PoolingAllocatorMetrics (#11490)

This exposes some basic runtime metrics derived from the internal state
of a `PoolingInstanceAllocator`.

Two new atomics were added to PoolingInstanceAllocator: `live_memories`
and `live_tables`. While these counts could be derived from existing
state it would require acquiring mutexes on some inner state.

show more ...

WebAssembly exception-handling support. (#11326)

* WebAssembly exception-handling support.

This PR introduces support for the [Wasm exception-handling proposal],
which introduces a conventional try

WebAssembly exception-handling support. (#11326)

* WebAssembly exception-handling support.

This PR introduces support for the [Wasm exception-handling proposal],
which introduces a conventional try/catch mechanism to WebAssembly. The
PR supports modules that use `try_table` to register handlers for a
lexical scope; and provides `throw` and `throw_ref` that allocate (in
the first case) and throw exception objects.

This PR builds on top of the work in #10510 for Cranelift-level
exception support, #10919 for an unwinder, and #11230 for exception
objects built on top of GC, in addition a bunch of smaller fix and
enabling PRs around those.

[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/

prtest:full

* Permit UnwindToWasm to have unused fields in Pulley builds (for now).

* Resolve miri-caught reborrowing issue.

* Ignore exceptions tests in miri for now (Pulley not supported).

* Use wasmtime_test on exceptions tests.

* Get tests passing on pulley platforms

* Add a check to `supports_host` for the generated test and assert
failure also when that is false.
* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`
* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`
* Remove miri annotations as they fall out of `#[wasmtime_test]`

* Remove dead import

* Skip some unsupported tests entirely in `#[wasmtime_test]`

If the selected compiler doesn't support the host at all then there's no
need to run it. Actually running it could misinterpret `CraneliftNative`
as "run with pulley" otherwise, so avoid such false negatives.

* Cranelift: dynamic contexts: account for outgoing-args area.

---------

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

show more ...

Resolve `unsafe_op_in_unsafe_fn` in `wasmtime` crate (#11432)

Just a few unsafe blocks remain

Closes #11180

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

fix(no_std)!: respect `std` feature when target is windows/unix (#11152)

* fix(no_std)!: respect `std` feature when target is windows/unix

BREAKING CHANGE: the fix disables standard features for de

fix(no_std)!: respect `std` feature when target is windows/unix (#11152)

* fix(no_std)!: respect `std` feature when target is windows/unix

BREAKING CHANGE: the fix disables standard features for dependents that use wasmtime with `default-features = false`.

* fix cargo check workflow

* Don't require `std` feature for invalid faults

Fill out the `compile_error!` to avoid failing a build.

* addressing review comments

* add `std` to `stack-switching` feature

* remove `rustix/mm` from `std` feature dependencies

* add `std` feature flag to `jit-icache-coherence`
- The `std` feature gates the use of standard library for icache coherence in Windows; otherwise, defaults to the `libc` implementation.
- The `std` feature of Wasmtime now depends on the `wasmtime-jit-icache-coherence/std`

* Only include jit-icache-coherence on `std` builds

prtest:full

* Fix some idiom issues

* More idiom issues

* Require `std` for loading native code

---------

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

show more ...

generalize async fiber abstraction (#11114)

* generalize async fiber abstraction

As part of the work implementing the new Component Model async ABI in the
`wasip3-prototyping` repo, I've generalize

generalize async fiber abstraction (#11114)

* generalize async fiber abstraction

As part of the work implementing the new Component Model async ABI in the
`wasip3-prototyping` repo, I've generalized the `FiberFuture` abstraction in
`wasmtime::runtime::store::async_` to support fibers which can either retain
exclusive access to the store across suspend points or release it. The latter
allows the store to be used by the `component-model-async` event loop and/or
other fibers to run before the original fiber resumes, which is the key to
allowing multiple fibers to run concurrently, passing control of the store back
and forth.

In the case of Pulley, the above generalization means we also need to give each
fiber its own `Interpreter` so that multiple concurrent fibers don't clobber
each other's state.

Concretely, this moves a lot of the code out of `async_.rs` and into a new
`fiber.rs` submodule which will be shared with the `component-model-async`
implementation.

This also pulls in a new `StoreToken<T>` utility which has been useful in
`wasip3-prototyping` to safely convert from a `&mut dyn VMStore` to a
`StoreContextMut<'a, T>` when we previously witnessed a conversion in the other
direction.

Note that I've added a `'static` bound to the `VMStore` trait, which simplifies
use of `&mut dyn VMStore`, avoiding thorny lifetime issues.

Signed-off-by: Joel Dice <[email protected]>

* address review feedback

Signed-off-by: Joel Dice <[email protected]>

* fix miri-flagged stacked borrow violation

As part of my earlier effort to unify the fiber abstractions in the `wasmtime`
crate, I changed a `*mut StoreFiber` field to a `&mut StoreFiber`, not realizing
that it resulted in a mutable alias at runtime and thus undefined behavior.
Miri caught it, fortunately.

Signed-off-by: Joel Dice <[email protected]>

* remove unneeded `Send` bounds

Signed-off-by: Joel Dice <[email protected]>

* address more review feedback

Main changes:

- Make `resume_fiber[_raw]` take a `&mut StoreOpaque` parameter to make its unsafe internals easier to reason about, safety-wise.

- Panic if `StoreFiber::drop` is called on an in-progress fiber without having called `StoreFiber::dispose` to gracefully end it first.

- (Re)introduce `FiberFuture`, which closes over a `&mut StoreOpaque` and uses it to call `StoreFiber::dispose` on drop.

This will require a few more changes to make it usable by `concurrent.rs`, but
I'll save those changes for a later PR.

Signed-off-by: Joel Dice <[email protected]>

* address more review feedback

Signed-off-by: Joel Dice <[email protected]>

* update `impl Send For StoreFiber` comment

Signed-off-by: Joel Dice <[email protected]>

* Remove currently-extraneous `Result<()>` from fibers

May be needed for concurrent bits, but for now not necessary.

* Use safe pointers instead of raw pointers

It's predicted Miri won't like this, but for now in-repo it's ok with it.

* Fold more responsibility into `resume_fiber_raw`

Remove the need for the function entirely and replace it with
`resume_fiber`.

* Remove channels from async fibers

Can use stack-based closures/results to transmit the result instead of
needing a channel.

* Fold `on_fiber_raw` directly into `on_fiber`

The `on_fiber` function is small enough it should be possible to do so.

* Don't use `Option` in `FiberFuture`

Leave the fiber non-optional at-rest so it's always available for the
destructor.

* Fold `suspend` functions together

Small shims, not otherwise public at this time, so remove a layer of
indirection.

* Move stack limit management to `FiberResumeState`

Helps remove some raw pointers that are held for a long time within
`AsyncCx`

* add some doc comments to `fiber.rs`

Signed-off-by: Joel Dice <[email protected]>

* update `fiber.rs` and friends to match CM async requirements

This adds a `resolve_or_release` function, which `Instance::resume_fiber` will
use when current `concurrent.rs` stub is replaced by a real implementation.

Signed-off-by: Joel Dice <[email protected]>

* fix non-component-model-async build warnings

Signed-off-by: Joel Dice <[email protected]>

* make `resume_fiber` private in `fiber.rs`

Signed-off-by: Joel Dice <[email protected]>

* Shrink `PollContext` state

Move management of the async guard range elsewhere to the normal
save/restore area.

* Refactor `AsyncCx`, reduce `unsafe`

* Remove the `AsyncCx` type from Wasmtime as it's inherently `unsafe` to
use, instead bundle operations directly on a `Store*` reference.

* Don't retain pointers-to-pointers within the roughly-equivalent
`BlockingContext` created in this PR. Instead when a blocking context
is created "take" the metadata from the store to assert exclusive
ownership of the pointers.

* Refactor how `&mut Context<'_>` is passed around, namely thread it
through fiber parameters to model resumption as registering a new
context to poll with.

* Remove `PollContext` in favor of directly storing a pointer as it's
now mostly an empty structure.

* Minor refactorings to make things more future-refactorable and/or
clear in a few places.

* Refactor management of the "current suspend" and "current future
context" pointers. These are now null'd out on resumption and asserted
null on suspension.

* Remove the need for a generic `Reset` structure in the fiber bits as
it's a pretty dangerous structure to have in general.

The end result of this refactoring is that all usage of `block_on` is
now safe and additionally many of the internals of the implementation
are safer than they were before

* Adjust some lint attributes

* Make manipulation of `AsyncState` safe

No need for raw pointers with recent refactorings.

* Fix dead code warning

* More dead code warnings

* Cut down on raw pointers in fiber.rs

* Move executor save/restore to normal fiber state save/restore

* Bikeshed a method name

* update comment in make_fiber

Signed-off-by: Joel Dice <[email protected]>

* fix machports build

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

show more ...

Start work towards always-warnings in wasmtime (#10131)

* Start work towards always-warnings in `wasmtime`

This commit is an attempt to make progress after #10108. The goal of
this commit is to cre

Start work towards always-warnings in wasmtime (#10131)

* Start work towards always-warnings in `wasmtime`

This commit is an attempt to make progress after #10108. The goal of
this commit is to create a list of features to burn down over time and
to have `dead_code` and `unused_imports` lints on-by-default in
Wasmtime. The `feature = "default"` gate on this `allow` directive was
replaced with individual features. The hope is that as individual
features are removed from this list we can fix the resulting warnings
and the commit such a ratchet.

* Burn down some features from allowing dead code

Remove the features from the crate and test compiling with all other
features to ensure that no warnings are issued.

* Run full tests in CI

prtest:full

* Fix warning condition

* Fix #[cfg] to fix warnings on iOS

Switch `target_os = "macos"` to `target_vendor = "apple"` to align
requirements.

show more ...

Upstream wasm-wave instances in wasmtime (#8872)

* wasmtime: add wasm-wave instances behind an off-by-default wave feature

* cargo vet: trust the usuals, audit beef, exempt logos family

* correct

Upstream wasm-wave instances in wasmtime (#8872)

* wasmtime: add wasm-wave instances behind an off-by-default wave feature

* cargo vet: trust the usuals, audit beef, exempt logos family

* correct unrelated comment

* wasmtime::component::wasm_wave re-exports the crate

* convenience functions: component::Val::{to_wave, from_wave}.

* fix componentfunc params

show more ...

Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)

* Warn against `clippy::cast_possible_truncation` in Wasmtime

This commit explicitly enables the `clippy::cast_possible_truncatio

Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)

* Warn against `clippy::cast_possible_truncation` in Wasmtime

This commit explicitly enables the `clippy::cast_possible_truncation`
lint in Clippy for just the `wasmtime::runtime` module. This does not
enable it for the entire workspace since it's a very noisy lint and in
general has a low signal value. For the domain that `wasmtime::runtime`
is working in, however, this is a much more useful lint. We in general
want to be very careful about casting between `usize`, `u32`, and `u64`
and the purpose of this module-targeted lint is to help with just that.
I was inspired to do this after reading over #9206 where especially when
refactoring code and changing types I think it would be useful to have
locations flagged as "truncation may happen here" which previously
weren't truncating.

The failure mode for this lint is that panics might be introduced where
truncation is explicitly intended. Most of the time though this isn't
actually desired so the more practical consequence of this lint is to
probably slow down wasmtime ever so slightly and bloat it ever so
slightly by having a few more checks in a few places. This is likely
best addressed in a more comprehensive manner, however, rather than
specifically for just this one case. This problem isn't unique to just
casts, but to many other forms of `.unwrap()` for example.

* Fix some casts in tests

show more ...

Add a compile-time feature for call hooks (#8795)

* Add a compile-time feature for call hooks

This commit moves the `Store::call_hook` API behind a Cargo feature
named `call-hook`. This helps speed

Add a compile-time feature for call hooks (#8795)

* Add a compile-time feature for call hooks

This commit moves the `Store::call_hook` API behind a Cargo feature
named `call-hook`. This helps speed up the path from wasm into the host
by avoiding branches at the start and the end of the execution. In a
thread on [Zulip] this is locally leading to significant performance
gains in this particular microbenchmark so having an option to disable
it at the crate layer seems like a reasonable way to thread this needle
for now. This definitely has a downside in that it requires a crate
feature at all, but I'm not sure of a better solution as LLVM can't
dynamically detect that `Store::call_hook` is never invoked and
therefore the branch can be optimized away.

[Zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Performance.20regression.20since.20rust.201.2E65/near/444505571

* Fix a feature build

show more ...

Wasmtime(pooling allocator): Batch decommits (#8590)

This introduces a `DecommitQueue` for batching decommits together in the pooling
allocator:

* Deallocating a memory/table/stack enqueues their a

Wasmtime(pooling allocator): Batch decommits (#8590)

This introduces a `DecommitQueue` for batching decommits together in the pooling
allocator:

* Deallocating a memory/table/stack enqueues their associated regions of memory
for decommit; it no longer immediately returns the associated slot to the
pool's free list. If the queue's length has reached the configured batch size,
then we flush the queue by running all the decommits, and finally returning
the memory/table/stack slots to their respective pools and free lists.

* Additionally, if allocating a new memory/table/stack fails because the free
list is empty (aka we've reached the max concurrently-allocated limit for this
entity) then we fall back to a slow path before propagating the error. This
slow path flushes the decommit queue and then retries allocation, hoping that
the queue flush reclaimed slots and made them available for this fallback
allocation attempt. This involved defining a new `PoolConcurrencyLimitError`
to match on, which is also exposed in the public embedder API.

It is also worth noting that we *always* use this new decommit queue now. To
keep the existing behavior, where e.g. a memory's decommits happen immediately
on deallocation, you can use a batch size of one. This effectively disables
queueing, forcing all decommits to be flushed immediately.

The default decommit batch size is one.

This commit, with batch size of one, consistently gives me an increase on
`wasmtime serve`'s requests-per-second versus its parent commit, as measured by
`benches/wasmtime-serve-rps.sh`. I get ~39K RPS on this commit compared to ~35K
RPS on the parent commit. This is quite puzzling to me. I was expecting no
change, and hoping there wouldn't be a regression. I was not expecting a speed
up. I cannot explain this result at this time.

prtest:full

Co-authored-by: Jamey Sharp <[email protected]>

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

Use rustdoc's `doc_auto_cfg` feature instead of `doc_cfg` (#8532)

This commit removes all our `#[cfg_attr(..., doc(cfg(...)))]`
annotations throughout Wasmtime and `wasmtime-wasi`. These are all
rep

Use rustdoc's `doc_auto_cfg` feature instead of `doc_cfg` (#8532)

This commit removes all our `#[cfg_attr(..., doc(cfg(...)))]`
annotations throughout Wasmtime and `wasmtime-wasi`. These are all
replaced with `feature(doc_auto_cfg)` which automatically infers the
attribute to show rather than requiring us to duplicate it.
Spot-checking the docs this looks just-as-readable while being much
easier to maintain over time.

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

Define garbage collection rooting APIs (#8011)

* Define garbage collection rooting APIs

Rooting prevents GC objects from being collected while they are actively being
used.

We have a few sometimes

Define garbage collection rooting APIs (#8011)

* Define garbage collection rooting APIs

Rooting prevents GC objects from being collected while they are actively being
used.

We have a few sometimes-conflicting goals with our GC rooting APIs:

1. Safety: It should never be possible to get a use-after-free bug because the
user misused the rooting APIs, the collector "mistakenly" determined an
object was unreachable and collected it, and then the user tried to access
the object. This is our highest priority.

2. Moving GC: Our rooting APIs should moving collectors (such as generational
and compacting collectors) where an object might get relocated after a
collection and we need to update the GC root's pointer to the moved
object. This means we either need cooperation and internal mutability from
individual GC roots as well as the ability to enumerate all GC roots on the
native Rust stack, or we need a level of indirection.

3. Performance: Our rooting APIs should generally be as low-overhead as
possible. They definitely shouldn't require synchronization and locking to
create, access, and drop GC roots.

4. Ergonomics: Our rooting APIs should be, if not a pleasure, then at least not
a burden for users. Additionally, the API's types should be `Sync` and `Send`
so that they work well with async Rust.

For example, goals (3) and (4) are in conflict when we think about how to
support (2). Ideally, for ergonomics, a root would automatically unroot itself
when dropped. But in the general case that requires holding a reference to the
store's root set, and that root set needs to be held simultaneously by all GC
roots, and they each need to mutate the set to unroot themselves. That implies
`Rc<RefCell<...>>` or `Arc<Mutex<...>>`! The former makes the store and GC root
types not `Send` and not `Sync`. The latter imposes synchronization and locking
overhead. So we instead make GC roots indirect and require passing in a store
context explicitly to unroot in the general case. This trades worse ergonomics
for better performance and support for moving GC and async Rust.

Okay, with that out of the way, this module provides two flavors of rooting
API. One for the common, scoped lifetime case, and another for the rare case
where we really need a GC root with an arbitrary, non-LIFO/non-scoped lifetime:

1. `RootScope` and `Rooted<T>`: These are used for temporarily rooting GC
objects for the duration of a scope. Upon exiting the scope, they are
automatically unrooted. The internal implementation takes advantage of the
LIFO property inherent in scopes, making creating and dropping `Rooted<T>`s
and `RootScope`s super fast and roughly equivalent to bump allocation.

This type is vaguely similar to V8's [`HandleScope`].

[`HandleScope`]: https://v8.github.io/api/head/classv8_1_1HandleScope.html

Note that `Rooted<T>` can't be statically tied to its context scope via a
lifetime parameter, unfortunately, as that would allow the creation and use
of only one `Rooted<T>` at a time, since the `Rooted<T>` would take a borrow
of the whole context.

This supports the common use case for rooting and provides good ergonomics.

2. `ManuallyRooted<T>`: This is the fully general rooting API used for holding
onto non-LIFO GC roots with arbitrary lifetimes. However, users must manually
unroot them. Failure to manually unroot a `ManuallyRooted<T>` before it is
dropped will result in the GC object (and everything it transitively
references) leaking for the duration of the `Store`'s lifetime.

This type is roughly similar to SpiderMonkey's [`PersistentRooted<T>`],
although they avoid the manual-unrooting with internal mutation and shared
references. (Our constraints mean we can't do those things, as mentioned
explained above.)

[`PersistentRooted<T>`]: http://devdoc.net/web/developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS::PersistentRooted.html

At the end of the day, both `Rooted<T>` and `ManuallyRooted<T>` are just tagged
indices into the store's `RootSet`. This indirection allows working with Rust's
borrowing discipline (we use `&mut Store` to represent mutable access to the GC
heap) while still allowing rooted references to be moved around without tying up
the whole store in borrows. Additionally, and crucially, this indirection allows
us to update the *actual* GC pointers in the `RootSet` and support moving GCs
(again, as mentioned above).

* Reorganize GC-related submodules in `wasmtime-runtime`

* Reorganize GC-related submodules in `wasmtime`

* Use `Into<StoreContext[Mut]<'a, T>` for `Externref::data[_mut]` methods

* Run rooting tests under MIRI

* Make `into_abi` take an `AutoAssertNoGc`

* Don't use atomics to update externref ref counts anymore

* Try to make lifetimes/safety more-obviously correct

Remove some transmute methods, assert that `VMExternRef`s are the only valid
`VMGcRef`, etc.

* Update extenref constructor examples

* Make `GcRefImpl::transmute_ref` a non-default trait method

* Make inline fast paths for GC LIFO scopes

* Make `RootSet::unroot_gc_ref` an `unsafe` function

* Move Hash and Eq for Rooted, move to impl methods

* Remove type parameter from `AutoAssertNoGc`

Just wrap a `&mut StoreOpaque` directly.

* Make a bunch of internal `ExternRef` methods that deal with raw `VMGcRef`s take `AutoAssertNoGc` instead of `StoreOpaque`

* Fix compile after rebase

* rustfmt

* revert unrelated egraph changes

* Fix non-gc build

* Mark `AutoAssertNoGc` methods inline

* review feedback

* Temporarily remove externref support from the C API

Until we can add proper GC rooting.

* Remove doxygen reference to temp deleted function

* Remove need to `allow(private_interfaces)`

* Fix call benchmark compilation

show more ...

Wasmtime: Add a `gc` cargo feature (#7975)

* Wasmtime: Add a `gc` cargo feature

This controls whether support for `ExternRef` and its associated deferred,
reference-counting garbage collector is en

Wasmtime: Add a `gc` cargo feature (#7975)

* Wasmtime: Add a `gc` cargo feature

This controls whether support for `ExternRef` and its associated deferred,
reference-counting garbage collector is enabled at compile time or not. It will
also be used for similarly for Wasmtime's full Wasm GC support as that gets
added.

* Add CI for `gc` Cargo feature

* Cut down on the number of `#[cfg(feature = "gc")]`s outside the implementation of `[VM]ExternRef`

* Fix wasmparser reference types configuration with GC disabled/enabled

* More config fix

* doc cfg

* Make the dummy `VMExternRefActivationsTable` inhabited

* Fix winch tests

* final review bits

* Enable wasmtime's gc cargo feature for the C API

* Enable wasmtime's gc cargo feature from wasmtime-cli-flags

* enable gc cargo feature in a couple other crates

show more ...

Fix more nightly warnings (#7907)

Additionally give `-Zcheck-cfg` a spin with Cargo and fix some mistakes
with our `--cfg` and `#[cfg]` directives.

Shuffle some items around in `wasmtime` (#7839)

* Shuffle some items around in `wasmtime`

This is a follow-up to #7766 with some more changes and reorganization.
These are some small items here and

Shuffle some items around in `wasmtime` (#7839)

* Shuffle some items around in `wasmtime`

This is a follow-up to #7766 with some more changes and reorganization.
These are some small items here and there which shouldn't have any
actual impact on functionality but are intended to reorganize a bit.
Changes here include:

* Move component artifact definitions to `wasmtime-environ` as core
module ones already live there.
* Rename the module with module artifacts from `instantiate` to
`module_artifacts`.
* Make `wasmtime-jit-icache-coherence` an optional dependency as only
the `runtime` feature requires it.
* Reorganize serialized metadata for wasmtime ELF files to consolidate
everything back into `wasmtime::engine::serialization`. This is to
prevent the definition of the serialization format being spread across
a few files.
* Touching up the `serialization` module to compile in all builds of the
`wasmtime` crate.

* fix docs typo

---------

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

show more ...

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be u

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be useful when cross-compiling, especially on a target that
can't run wasmtime itself (e.g. `wasm32`).

* prtest:full

* don't round pages without runtime feature

* fix async assertions

* move profiling into runtime

* enable runtime for wasmtime-wasi

* enable runtime for c-api

* fix build_artifacts in non-cache case

* fix miri extensions

* enable runtime for wast

* enable runtime for explorer

* support cranelift all-arch on wasm32

* add doc links for `WeakEngine`

* simplify lib runtime cfgs

* move limits and resources to runtime

* move stack to runtime

* move coredump and debug to runtime

* add runtime to coredump and async features

* add wasm32 build job

* combine engine modules

* single compile mod

* remove allow for macro paths

* add comments

show more ...