Config knobs and validation for record-replay (#12375)

Migrate CLI flags to `wasmtime::error` (#12260)

Bump Wasmtime to 40.0.0 (#11983)

Co-authored-by: Wasmtime Publish <[email protected]>

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

Stack switching: Infrastructure and runtime support (#10388)

* [pr1] base

* prtest:full

* make sure to use ControlFlow result in trace_suspended_continuation

* stack-switching: cleanup: remove st

Stack switching: Infrastructure and runtime support (#10388)

* [pr1] base

* prtest:full

* make sure to use ControlFlow result in trace_suspended_continuation

* stack-switching: cleanup: remove stray c-api changes

These are remnants of unrelated wasmfx wasmtime experiments, possibly
suitable for later submission against upstream.

* stack-switching: reuse async_stack_size

* stack-switching: delete delete_me debugging

* stack-switching: address feedback in environ::types

* stack-switching: remove unused code from vmoffsets

* stack-switching: drop dependency on std

* stack-switching: add compilation checks to ci matrix

* stack-switching: remove debug_println cruft

* stack-switching: export environ consts consistently

* stack-switching: export vm pub items consistently

* table_pool: reduced capacity for large elements

VMContRef elements which takes up two words and we don't want to
double the size of all tables in order to support storing these.
This change changes the table to target storing the requested
max number of elements if they are "nominally" sized with
(potentially) reduced capacity for non-nominally sized types when
encountered.

Continuations are the only type of element which may result in
fewer table slots being available than requested.

* stack-switching: extend conditional compilation

A fair bit of the definitions for stack switching are still
enabled, but this patch takes things a bit further to avoid
compilation problems; notably, cont_new is now not compiled
in unless the feature is enabled.

* stack-switching: formatting fixes

* stack-switching: address new clippy checks

In addition, to get clippy to fully pass, plumbed in
additional config to make winch paths happy; there's no
impl for winch yet but plumbing through the feature is
required to make paths incorporating macros at various
layers satisfied (and it is expected we'll use the
features in the future).

* stack-switching: more conditional compilation fixes

* stack-switching: additional conditional compile on table builtins for continuations

* stack-switching: additional conditional compile fixes

* stack-switching: additional conditional compile in store

* stack-switching: remove overly strict assertion

* stack-switching: remove errantly dropped no_mangle in config c-api

* stack-switching: VMContObj::from_raw_parts

* stack-switching: remove duplicate async_stack_size feature check

* stack-switching: VMArray -> VMHostArray

* stack-switching: remove unnecessary clippy exception

* stack-switching: fix docs referenced VMRuntimeLimits

* stack-switching: fix doc typo

* stack-switching: follow recommendations for type casts

* stack-switching: use usize::next_multiple_of

* stack-switching: update outdated comment

* stack-switching: use feature gate instead of allow(dead_code)

* stack-switching: rework backtrace using chunks/zip

* stack-switching: move tests to footer module

This is a bit more consistent with the prevailing style
in tree and (subjectively) makes finding the tests
as a reader more straightforward.

Tests left unchanged sans some import cleanup.

* stack-swictchding: verify stack_chain offsets at runtime

* fixup! stack-switching: use feature gate instead of allow(dead_code)

* stack-switching: document continuation roots tracing using match arms

---------

Co-authored-by: Paul Osborne <[email protected]>

show more ...

Remove humantime crate dependency (#10379)

Turns out this has been unmaintained for quite some time now. It
additionally is only a fringe benefit so hand-write a few parsers to
replace it.

Closes #

Remove humantime crate dependency (#10379)

Turns out this has been unmaintained for quite some time now. It
additionally is only a fringe benefit so hand-write a few parsers to
replace it.

Closes #10378

show more ...

Create wasmtime::Config from toml (#9811)

* Create wasmtime::Config from toml, add --config CLI flag

* Add cli tests

Make it easier to reuse fuzzing configuration on the CLI (#10123)

* Make it easier to reuse fuzzing configuration on the CLI

During fuzzing we emit a debug log of configured options to assist with

Make it easier to reuse fuzzing configuration on the CLI (#10123)

* Make it easier to reuse fuzzing configuration on the CLI

During fuzzing we emit a debug log of configured options to assist with
reproducing fuzz test cases outside of the fuzzing harness. Mapping
options the fuzzer is using though to CLI flags, for example, is a bit
of an art though and not obvious. Just today we've got a fuzz bug and I
couldn't figure out how to reproduce on the CLI and it turns out the
issue was that I was forgetting a flag that was being configured in
response to another flag. I got a bit fed up with constantly trying to
map one to the other, so I've decided to fix things.

This commit adds a `Display for CommonOptions` implementation to the
`wasmtime-cli-flags` crate. This is built on the same macro-construction
infrastructure of all our flags making it a relatively low one-time-cost
to implement this. Each option value now implements not only parsing but
printing as well.

Next the `wasmtime-fuzzing` crate was updated to create a
`CommonOptions` first which is then in turn used to create a
`wasmtime::Config`. This provides a layer to insert a log statement with
to emit all configuration options in a form that can be easily
copy/pasted to the CLI to reproduce.

Overall after doing this I was able to quickly reproduce the bug in
question (yay!). The CLI flag logging is pretty verbose right now since
the fuzzing infrastructure sets many settings redundantly to their
defaults, but reducing flags to a minimum is expected to be relatively
easy compared to otherwise trying to extract the options.

* Fix build and dependencies from wasmtime-fuzzing

* Always provide `wasmtime::MpkEnabled`

It's an otherwise very small `enum` which makes it easier to
conditionally compile `wasmtime-cli-flags`

* Frob some crate features some more

* Fix specification of `wasmtime_linkopt_force_jump_veneer` option

show more ...

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the

Replace `signals-based-traps` with auto-detection (#9941)

* Replace `signals-based-traps` with auto-detection

This commit refactors the platform support of the `wasmtime` crate
itself to remove the previously added `signals-based-traps` feature in
favor of auto-detecting whether it's there or not. The `build.rs`
script for the `wasmtime` crate will now detect the target platform and
auto-enable this feature as necessary.

The `signals-based-traps` cargo feature is removed and split into two
custom `#[cfg]` directives that the build script sets:

* `has_virtual_memory` - this is used to gate mmap implementations for
example. This is enabled on `unix || windows` and will be off for
`no_std` targets for example. This is split out of
"signals-based-traps" to better handle platforms like iOS which have
virtual memory but don't execute native code (removing the need for
native signals).

* `has_native_signals` - gates signal handlers on Unix for example. This
is disabled on MIRI but otherwise enabled for `unix || windows`. This
is intended to in the future get disabled for iOS by default for
example since it's not necessary when using Pulley. This is
additionally off-by-default for `no_std` platforms.

Two new crate features were added for `no_std` or "custom" platforms to
opt-in to the `wasmtime-platform.h` C APIs for implementing virtual
memory and signals. These are used in the `min-platform` embedding example.

This commit additionally updates some various documentation here and
there to be more up-to-date.

* Update CI configuration

* Fix compile warnings

* Fix test on miri

* Fix more tests on miri

* Fix some warnings

* Another round of miri/CI attempts/fixes

prtest:full

show more ...

Enable `pulley` by default for the `wasmtime` CLI (#9983)

Now that pulley is nearing completion this makes it more useful to test
out the interpreter on the CLI by having it available by default on

Enable `pulley` by default for the `wasmtime` CLI (#9983)

Now that pulley is nearing completion this makes it more useful to test
out the interpreter on the CLI by having it available by default on all
platforms.

show more ...

Don't forcibly enable `gc` feature with cli-flags crate (#9887)

* Don't forcibly enable `gc` feature with cli-flags crate

Helps keep the `gc` feature out of the "min" build.

* Fix standalone build

Don't forcibly enable `gc` feature with cli-flags crate (#9887)

* Don't forcibly enable `gc` feature with cli-flags crate

Helps keep the `gc` feature out of the "min" build.

* Fix standalone build of wasmtime-cli-flags

show more ...

Add a `signals-based-traps` Cargo compile-time feature (#9614)

* Gate signal handlers behind a new Cargo feature

This commit adds a new on-by-default Cargo feature to the `wasmtime`
crate named `si

Add a `signals-based-traps` Cargo compile-time feature (#9614)

* Gate signal handlers behind a new Cargo feature

This commit adds a new on-by-default Cargo feature to the `wasmtime`
crate named `signals-based-traps`. This is modeled after the
`Config::signals_based_traps` configuration at runtime and can be used
to statically disable the use of signal handlers in Wasmtime. This
notably reduces the number of platform dependencies that Wasmtime has
and provides a mode of avoiding relying on signals altogether.

This introduces a new `MallocMemory` which is a linear memory backed by
the system allocator. This new type of memory is enabled when virtual
memory guards are disabled and signals-based-traps are disabled. This
means that this new type of memory will be candidate for fuzzing for
example.

prtest:full

* Fix rebase conflict

* Refactor `MmapVec` documentation and representation

* Remove no-longer-needed `Arc`
* Document it may be backed by `Vec<u8>`

show more ...

Add the "null" garbage collector (#9484)

* Add the "null" garbage collector

The null collector does not actually collect any garbage, it simply
bump-allocates until the heap is exhausted, at which

Add the "null" garbage collector (#9484)

* Add the "null" garbage collector

The null collector does not actually collect any garbage, it simply
bump-allocates until the heap is exhausted, at which point further allocation
attempts will fail. It does not require any GC barriers.

Users can configure which collector to use via the `wasmtime::Config::collector`
method or the `-C collector=drc|null` CLI flag. The `wasmtime::Collector` enumeration,
similar to the `wasmtime::Strategy` enumeration but for choosing a collector
rather than a compiler, additionally has a table summarizing the properties and
characteristics of our current set of collector implementations.

Finally, we also run `.wast` tests that exercise GC types under both the DRC and
null collectors. I tried to avoid running tests that are not related to GC under
both configurations just to avoid a combinatorial blow up.

* cargo fmt

* fix +gc -gc-null -gc-drc build

* Fix some warnings in various cargo feature combo builds

* Fix some more warnings in certain build configs

* Fix unit tests for null GC

* Fill in some placeholder comments that I forgot to write

* Fix issues where we ask for a GC store when we don't actually need one

Which was causing test failures, since we no longer return a GC store with a
dummy heap.

* Add fuzzing config support for different collectors

* address review feedback

* fix cmake tests

* Fix test compilation after rebase

* Fix GC tests under MIRI

show more ...

Add `rust-version.workspace = true` to all crates (#9112)

Right now this is only on some crates such as `wasmtime` itself and
`wasmtime-cli`, but by applying it to all crates it helps with version
s

Add `rust-version.workspace = true` to all crates (#9112)

Right now this is only on some crates such as `wasmtime` itself and
`wasmtime-cli`, but by applying it to all crates it helps with version
selection of those using just Cranelift for example.

show more ...

Fix build of `wasmtime-cli` with only the pooling allocator enabled (#8891)

Fixes #8889

Disable memory protection keys by default at compile time (#8813)

* Disable memory protection keys by default at compile time

This commit gates memory protection keys behind a new Cargo feature
whi

Disable memory protection keys by default at compile time (#8813)

* Disable memory protection keys by default at compile time

This commit gates memory protection keys behind a new Cargo feature
which is disabled by default. Memory protection keys are already
disabled by default on all platforms and are only configured to possibly
work with Linux x64. When enabled, however, it unconditionally adds a
small amount of overhead to WebAssembly entries/exits even if the
feature is disabled at runtime for the same reason that the `call-hook`
feature adds overhead. With `call-hook` being disabled by default
in #8808 it seemed reasonable to additionally gate memory protection
keys to avoid needing to disable features in Wasmtime to get the best
performance wasm<->host calls.

* Enable Wasmtime feature for fuzzing

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

Gate support for the wasm `threads` proposal behind a Cargo feature (#8260)

* Gate support for the wasm `threads` proposal behind a Cargo feature

This commit moves support for the `threads` proposa

Gate support for the wasm `threads` proposal behind a Cargo feature (#8260)

* Gate support for the wasm `threads` proposal behind a Cargo feature

This commit moves support for the `threads` proposal behind a new
on-by-default Cargo feature: `threads`. This is intended to support
building Wasmtime with fewer runtime dependencies such as those required
for the atomic operations on memories.

This additionally adds the `gc` feature in a few missing places too.

* Fix compile of C API without threads

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

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at th

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at the workspace level in Wasmtime rather than the crate level. This
uses a feature of Cargo first released with 1.74.0 (last week) of the
`[workspace.lints]` table. This should help create a more consistent set
of lints applied across all crates in our workspace in addition to
possibly running select clippy lints on CI as well.

* Move `unused_extern_crates` to the workspace level

This commit configures a `deny` lint level for the
`unused_extern_crates` lint to the workspace level rather than the
previous configuration at the individual crate level.

* Move `trivial_numeric_casts` to workspace level

* Change workspace lint levels to `warn`

CI will ensure that these don't get checked into the codebase and
otherwise provide fewer speed bumps for in-process development.

* Move `unstable_features` lint to workspace level

* Move `unused_import_braces` lint to workspace level

* Start running Clippy on CI

This commit configures our CI to run `cargo clippy --workspace` for all
merged PRs. Historically this hasn't been all the feasible due to the
amount of configuration required to control the number of warnings on
CI, but with Cargo's new `[lint]` table it's possible to have a
one-liner to silence all lints from Clippy by default. This commit by
default sets the `all` lint in Clippy to `allow` to by-default disable
warnings from Clippy. The goal of this PR is to enable selective access
to Clippy lints for Wasmtime on CI.

* Selectively enable `clippy::cast_sign_loss`

This would have fixed #7558 so try to head off future issues with that
by warning against this situation in a few crates. This lint is still
quite noisy though for Cranelift for example so it's not worthwhile at
this time to enable it for the whole workspace.

* Fix CI error

prtest:full

show more ...

Add compatibility shims for Wasmtime 13 CLI (#7385)

* Add compatibility shims for Wasmtime 13 CLI

This commit introduces a compatibility shim for the Wasmtime 13 CLI and
prior. The goal of this com

Add compatibility shims for Wasmtime 13 CLI (#7385)

* Add compatibility shims for Wasmtime 13 CLI

This commit introduces a compatibility shim for the Wasmtime 13 CLI and
prior. The goal of this commit is to address concerns raised in #7336
and other locations as well. While the new CLI cannot be un-shipped at
this point this PR attempts to ameliorate the situation somewhat through
a few avenues:

* A complete copy of the old CLI parser is now included in `wasmtime` by
default.
* The `WASMTIME_NEW_CLI=0` environment variable can force usage of the
old CLI parser for the `run` and `compile` commands.
* The `WASMTIME_NEW_CLI=1` environment variable can force usage of the
new CLI parser.
* Otherwise both the old and the new CLI parser are executed. Depending
on the result one is selected to be executed, possibly with a warning
printed.
* If both CLI parsers succeed but produce the same result, then no
warning is emitted and execution continues as usual.
* If both CLI parsers succeed but produce different results then a
warning is emitted indicating this. The warning points to #7384 which
has further examples of how to squash the warning. The warning also
mentions the above env var to turn the warning off. In this situation
the old semantics are used at this time instead of the new semantics.
It's intended that eventually this will change in the future.
* If the new CLI succeeds and the old CLI fails then the new semantics
are executed without warning.
* If the old CLI succeeds and the new CLI fails then a warning is issued
and the old semantics are used.
* If both the old and the new CLI fail to parse then the error message
for the new CLI is emitted.

Note that this doesn't add up to a perfect transition. The hope is that
most of the major cases of change at the very least have something
printed. My plan is to land this on `main` and then backport it to the
14.0.0 branch as a 14.0.3 release.

* Wordsmith messages

* Update messages

* More wording updates

* Fix grammar

* More updates

show more ...

Gate many CLI/Wasmtime features behind Cargo features (#7282)

* Move `wasmtime explore` behind a Cargo feature

Enable this Cargo feature by default, but enable building the CLI
without the `explore

Gate many CLI/Wasmtime features behind Cargo features (#7282)

* Move `wasmtime explore` behind a Cargo feature

Enable this Cargo feature by default, but enable building the CLI
without the `explore` subcommand.

* Move the `wast` subcommand behind a Cargo feature

* Move support for `wat` behind a CLI feature

This was already conditional in crates such as `wasmtime` and this makes
it an optional dependency of the CLI as well.

* Move CLI cache support behind a Cargo feature

Additionally refactor `wasmtime-cli-flags` to not unconditionally pull
in caching support by removing its `default` feature and appropriately
enabling it from the CLI.

* Move `rayon` behind an optional feature

* Move `http-body-util` dependency behind `serve` feature

* Add a Cargo feature for compiling out log statements

This sets the static features of `log` and `tracing` to statically
remove all log statements from the binary to cut down on binary size.

* Move logging support behind a Cargo feature

Enables statically removing logging support in addition to the previous
compiling out log statements themselves.

* Move demangling support behind a Cargo feature

* Enable building the CLI without cranelift

Compile out the `compile` subcommand for example.

* Gate all profiling support behind one feature flag

This commit moves vtune/jitdump support behind a single `profiling`
feature flag that additionally includes the guest profiler dependencies
now too.

* Move support for core dumps behind a feature flag

* Move addr2line behind a feature

* Fix rebase

* Document cargo features and a minimal build

* Tidy up the source a bit

* Rename compile-out-logging

* Document disabling logging

* Note the host architecture as well

* Fix tests

* Fix tests

* Mention debuginfo stripping

* Fix CI configuration for checking features

* Fix book tests

* Update lock file after rebase

* Enable coredump feature by default

show more ...

Minor logging tweaks (#7242)

Some things I noticed from #7239 which are very much not critical but I
figure might be nice-to-haves:

* Move the logging configuration to the `wasmtime-cli-flags` crat

Minor logging tweaks (#7242)

Some things I noticed from #7239 which are very much not critical but I
figure might be nice-to-haves:

* Move the logging configuration to the `wasmtime-cli-flags` crate with
the other logging configuration to keep it in one place.
* Remove `pretty_env_logger` since `tracing-subscriber` probably
supplants it.
* Don't explicitly inherit env vars in tests since that happens
automatically with `Command`.

show more ...

Redesign Wasmtime's CLI (#6925)

* Redesign Wasmtime's CLI

This commit follows through on discussion from #6741 to redesign the
flags that the `wasmtime` binary accepts on the CLI. Almost all flags

Redesign Wasmtime's CLI (#6925)

* Redesign Wasmtime's CLI

This commit follows through on discussion from #6741 to redesign the
flags that the `wasmtime` binary accepts on the CLI. Almost all flags
have been renamed/moved and will require callers to update. The main
motivation here is to cut down on the forest of options in `wasmtime -h`
which are difficult to mentally group together and understand.

The main change implemented here is to move options behind "option
groups" which are intended to be abbreviated with a single letter:

* `-O foo` - an optimization or performance-tuning related option
* `-C foo` - a codegen option affecting the compilation process.
* `-D foo` - a debug-related option
* `-W foo` - a wasm-related option, for example changing wasm semantics
* `-S foo` - a WASI-related option, configuring various proposals for example

Each option group can be explored by passing `help`, for example `-O
help`. This will print all options within the group along with their
help message. Additionally `-O help-long` can be passed to print the
full comment for each option if desired.

Option groups can be specified multiple times on the command line, for
example `-Wrelaxed-simd -Wthreads`. They can also be combined together
with commas as `-Wrelaxed-simd,threads`. Configuration works as a "last
option wins" so `-Ccache,cache=n` would end up with a compilation
cache disabled.

Boolean options can be specified as `-C foo` to enable `foo`, or they
can be specified with `-Cfoo=$val` with any of `y`, `n`, `yes`, `no`,
`true`, or `false`. All other options require a `=foo` value to be
passed and the parsing depends on the type.

This commit additionally applies a few small refactorings to the CLI as
well. For example the help text no longer prints information about wasm
features after printing the option help. This is still available via
`-Whelp` as all wasm features have moved from `--wasm-features` to `-W`.
Additionally flags are no longer conditionally compiled in, but instead
all flags are always supported. A runtime error is returned if support
for a flag is not compiled in. Additionally the "experimental" name of
WASI proposals has been dropped in favor of just the name of the
proposal, for example `--wasi nn` instead of `--wasi-modules
experimental-wasi-nn`. This is intended to mirror how wasm proposals
don't have "experimental" in the name and an opt-in is required
regardless.

A full listing of flags and how they have changed is:

| old cli flag | new cli flag |
|-----------------------------------------------|-------------------------------------------------|
| `-O, --optimize` | removed |
| `--opt-level <LEVEL>` | `-O opt-level=N` |
| `--dynamic-memory-guard-size <SIZE>` | `-O dynamic-memory-guard-size=...` |
| `--static-memory-forced` | `-O static-memory-forced` |
| `--static-memory-guard-size <SIZE>` | `-O static-memory-guard-size=N` |
| `--static-memory-maximum-size <MAXIMUM>` | `-O static-memory-maximum-size=N` |
| `--dynamic-memory-reserved-for-growth <SIZE>` | `-O dynamic-memory-reserved-for-growth=...` |
| `--pooling-allocator` | `-O pooling-allocator` |
| `--disable-memory-init-cow` | `-O memory-init-cow=no` |
| `--compiler <COMPILER>` | `-C compiler=..` |
| `--enable-cranelift-debug-verifier` | `-C cranelift-debug-verifier` |
| `--cranelift-enable <SETTING>` | `-C cranelift-NAME` |
| `--cranelift-set <NAME=VALUE>` | `-C cranelift-NAME=VALUE` |
| `--config <CONFIG_PATH>` | `-C cache-config=..` |
| `--disable-cache` | `-C cache=no` |
| `--disable-parallel-compilation` | `-C parallel-compilation=no` |
| `-g` | `-D debug-info` |
| `--disable-address-map` | `-D address-map=no` |
| `--disable-logging` | `-D logging=no` |
| `--log-to-files` | `-D log-to-files` |
| `--coredump-on-trap <PATH>` | `-D coredump=..` |
| `--wasm-features all` | `-W all-proposals` |
| `--wasm-features -all` | `-W all-proposals=n` |
| `--wasm-features bulk-memory` | `-W bulk-memory` |
| `--wasm-features multi-memory` | `-W multi-memory` |
| `--wasm-features multi-value` | `-W multi-value` |
| `--wasm-features reference-types` | `-W reference-types` |
| `--wasm-features simd` | `-W simd` |
| `--wasm-features tail-call` | `-W tail-call` |
| `--wasm-features threads` | `-W threads` |
| `--wasm-features memory64` | `-W memory64` |
| `--wasm-features copmonent-model` | `-W component-model` |
| `--wasm-features function-references` | `-W function-references` |
| `--relaxed-simd-deterministic` | `-W relaxed-simd-deterministic` |
| `--enable-cranelift-nan-canonicalization` | `-W nan-canonicalization` |
| `--fuel <N>` | `-W fuel=N` |
| `--epoch-interruption` | `-W epoch-interruption` |
| `--allow-unknown-exports` | `-W unknown-exports-allow` |
| `--trap-unknown-imports` | `-W unknown-imports-trap` |
| `--default-values-unknown-imports` | `-W unknown-imports-default` |
| `--max-instances <MAX_INSTANCES>` | `-W max-instances=N` |
| `--max-memories <MAX_MEMORIES>` | `-W max-memories=N` |
| `--max-memory-size <BYTES>` | `-W max-memory-size=N` |
| `--max-table-elements <MAX_TABLE_ELEMENTS>` | `-W max-table-elements=N` |
| `--max-tables <MAX_TABLES>` | `-W max-tables=N` |
| `--max-wasm-stack <MAX_WASM_STACK>` | `-W max-wasm-stack=N` |
| `--trap-on-grow-failure` | `-W trap-on-grow-failure` |
| `--wasm-timeout <TIME>` | `-W timeout=N` |
| `--wmemcheck` | `-W wmemcheck` |
| `--wasi-modules default` | removed |
| `--wasi-modules -default` | removed |
| `--wasi-modules wasi-common` | `-S common` |
| `--wasi-modules -wasi-common` | `-S common=n` |
| `--wasi-modules experimental-wasi-nn` | `-S nn` |
| `--wasi-modules experimental-wasi-threads` | `-S threads` |
| `--wasi-modules experimental-wasi-http` | `-S http` |
| `--listenfd` | `-S listenfd` |
| `--tcplisten <SOCKET ADDRESS>` | `-S tcplisten=...` |
| `--wasi-nn-graph <FORMAT::HOST>` | `-S nn-graph=FORMAT::HOST` |
| `--preview2` | `-S preview2` |
| `--dir <DIRECTORY>` | `--dir ...` |
| `--mapdir <GUEST_DIR::HOST_DIR>` | `--dir a::b` |

* Be more descriptive with help text

* Document `=val` is optional for `-Ccranelift-xxx`

* Fix compile after rebase

* Fix rebase of `--inherit-network`

* Fix wasi-http test

* Fix compile without pooling allocator support

* Update some flags in docs

* Fix bench-api build

* Update flags for gdb/lldb tests

* Fixup optimization flags

prtest:full

show more ...

Fix testing cli-flags crate with component-model feature (#6831)

Not used on CI yet but it's part of an upcoming change I figured I'd
split out.