Migrate `crates/bench-api` to `wasmtime::error` instead of `anyhow` (#12258)

Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}" (#11380)

* Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}"

This commit renames the `preview1` module and features to `p1` and does
the same

Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}" (#11380)

* Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}"

This commit renames the `preview1` module and features to `p1` and does
the same for `preview0`. This additionally cleans up the test suite a
bit to share more code amongst all the implementaitons and to also move
the p1 tests out of the p2 folder.

This additionally adds a `p2` feature to the `wasmtime-wasi` crate but
it does not currently gate the `p2` module because that'll require some
more refactoring an annotations to get that working.

* Fix build of the CLI

* Fix build of the C API

* Fix bench-api build

* Fix build of examples

* More renamings

show more ...

Unify WASIp{2,3} context structures (#11370)

This removes `wasmtime_wasi::p{2,3}::{WasiCtx, WasiCtxBuilder,
WasiView}` in favor of only having `wasmtime_wasi::{WasiCtx,
WasiCtxBuilder, WasiView}` in

Unify WASIp{2,3} context structures (#11370)

This removes `wasmtime_wasi::p{2,3}::{WasiCtx, WasiCtxBuilder,
WasiView}` in favor of only having `wasmtime_wasi::{WasiCtx,
WasiCtxBuilder, WasiView}` instead. Conceptually these revisions of WASI
all provide the same functionality just with a different veneer that the
component model offers, so having only one way to configure host-side
behavior will make it easier to both organize implementations internally
(e.g. more sharing of code) as well as for embedders to configure (only
one context to create/manage).

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

Allow creation of a CacheConfig without loading from a file (#10665)

* cache: Add builder pattern for CacheConfig

* wasmtime: Add cache_config method to wasmtime::Config

* Refactor test_builder_de

Allow creation of a CacheConfig without loading from a file (#10665)

* cache: Add builder pattern for CacheConfig

* wasmtime: Add cache_config method to wasmtime::Config

* Refactor test_builder_default to use test_prolog helper

* Remove enabled option from CacheConfigBuilder and always set to true

* Change builder methods to take &mut self and return &mut Self

* Simplify cache configuration API

A new `cache_config(Option<CacheConfig>)` method replaces multiple methods
for controlling module caching. Now `None` disables caching, and users can
directly provide a cache config or load one from a file.

* Make cache configuration optional

* Add Cache struct to separate configuration from runtime (wip)

* Ensure default values earlier

* Consolidate CacheConfig and CacheConfigBuilder

* Set Cache directly on wastime::Config and make it easier to create one
from a file

* Validate after loading file again

* Move cache to top-level module

* Fix tests

show more ...

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

* Enable `unsafe-attr-outside-unsafe` 2024 edition lint

This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used
in tran

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

* Enable `unsafe-attr-outside-unsafe` 2024 edition lint

This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used
in transitioning to the 2024 edition. This requires that the
`#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`.
This mostly affects the C API of wasmtime and most of the changes here
are a simple search/replace.

* Another attribute update

* Fix command adapter build

show more ...

Bench API: Enable Pulley and allow recompiling with the same bench engine (#9877)

* bench-api: Allow recompiling with the same engine

* Enable Pulley in the bench API

Start plumbing the ability to run Pulley in Wasmtime (#9646)

* Start plumbing the ability to run Pulley in Wasmtime

This commit starts setting up some infrastructure to run Pulley modules
in Wasmti

Start plumbing the ability to run Pulley in Wasmtime (#9646)

* Start plumbing the ability to run Pulley in Wasmtime

This commit starts setting up some infrastructure to run Pulley modules
in Wasmtime, for example on the CLI. This doesn't actually work just yet
due to other missing pieces of integration but this is enough to get to
a fault and/or other compiler errors at this time. The changes here are:

* An `Engine` allows mismatching targets in the case of Pulley, but the
pointer widths must match.
* All subcommands of Wasmtime now support `--target`, e.g. `wasmtime
run`, as previously only the host was allowed.

* Fix compile of bench-api

* Fix miri tests

* Switch from `NativeEndian` to `Endianness`

This switches parsing ELF from always using the native endianness to
instead using a runtime-defined value of endianness. This enables
big-endian platforms such as s390x to load objects produced for pulley,
a little-endian platform.

show more ...

Enforce `uninlined_format_args` for the workspace (#9065)

* Enforce `uninlined_format_args` for the workspace

* fix: failing `Monolith Checks` job

* fix: formatting

wasi-nn: use resources (#8873)

* wasi-nn: use resources

Recent discussion in the wasi-nn proposal (see [wasi-nn#59], e.g.) has
concluded that the right approach for representing wasi-nn "things"
(t

wasi-nn: use resources (#8873)

* wasi-nn: use resources

Recent discussion in the wasi-nn proposal (see [wasi-nn#59], e.g.) has
concluded that the right approach for representing wasi-nn "things"
(tensors, graph, etc.) is with a component model _resource_. This
sweeping change brings Wasmtime's implementation in line with that
decision.

Initially I had structured this PR to remove all of the WITX-based
implementation (#8530). But, after consulting in a Zulip [thread] on
what other WASI proposals aim to do, this PR pivoted to support _both_`
the WITX-based and WIT-based ABIs (e.g., preview1 era versus preview2,
component model era). What is clear is that the WITX-based specification
will remain "frozen in time" while the WIT-based implementation moves
forward.

What that means for this PR is a "split world" paradigm. In many places,
we have to distinguish between the `wit` and `witx` versions of the same
thing. This change isn't the end state yet: it's a big step forward
towards bringing Wasmtime back in line with the WIT spec but, despite my
best efforts, doesn't fully fix all the TODOs left behind over several
years of development. I have, however, taken the liberty to refactor and
fix various parts as I came across them (e.g., the ONNX backend). I plan
to continue working on this in future PRs to figure out a good error
paradigm (the current one is too wordy) and device residence.

[wasi-nn#59]: https://github.com/WebAssembly/wasi-nn/pull/59
[thread]: https://bytecodealliance.zulipchat.com/#narrow/stream/219900-wasi/topic/wasi-nn's.20preview1.20vs.20preview2.20timeline

prtest:full

* vet: audit `ort`-related crate updates

* Simplify `WasiNnView`

With @alexcrichton's help, this change removes the `trait WasiNnView`
and `struct WasiNnImpl` wrapping that the WIT-based implementation used
for accessing the host context. Instead, `WasiNnView` is now a `struct`
containing the mutable references it needs to make things work. This
unwraps one complex layer of abstraction, though it does have the
downside that it complicates CLI code to split borrows of `Host`.

* Temporarily disable WIT check

* Refactor errors to use `trappable_error_type`

This change simplifies the return types of the host implementations of
the WIT-based wasi-nn. There is more work to be done with errors, e.g.,
to catch up with the upstream decision to return errors as resources.
But this is better than the previous mess.

show more ...

Respect pooling allocation options in `wasmtime serve` (#8525)

* Respect pooling allocation options in `wasmtime serve`

This commit updates the processing of pooling allocator options in
`wasmtime

Respect pooling allocation options in `wasmtime serve` (#8525)

* Respect pooling allocation options in `wasmtime serve`

This commit updates the processing of pooling allocator options in
`wasmtime serve`. Previously the pooling allocator was enabled by
default but the options to configure it weren't processed due to how
this default-enable was implemented. The option to enable it by default
for `wasmtime serve`, but only `wasmtime serve`, is now processed
differently in a way that handles various other
pooling-allocator-related options.

Closes #8504

* Fix compile of bench api

* Fix test build

* Ignore newly added test as it's flaky

show more ...

Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)

* WIP: try to make wasi-common self contained.

* rebase: cargo.lock

* remove all dependencies between wasi-common and

Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)

* WIP: try to make wasi-common self contained.

* rebase: cargo.lock

* remove all dependencies between wasi-common and wasmtime-wasi

* use wasi-common directly throughout tests, benches, examples, cli run

* wasi-threads: use wasi-common's maybe_exit_on_error in spawned thread

not a very modular design, but at this point wasi-common and
wasi-threads are forever wed

* fix wasmtime's docs

* re-introduce wasmtime-wasi's exports of wasi-common definitions behind deprecated

* factor out determining i32 process exit code

and remove libc dep because rustix provides the same constant

* commands/run: inline the logic about aborting on trap

since this is the sole place in the codebase its used

* Add high-level summary to wasi-common's top-level doc comment.

* c-api: fix use of wasi_cap_std_sync => wasi_common::sync, wasmtime_wasi => wasi_common

* fix tokio example

* think better of combining downcast and masking into one method

* fix references to wasmtime_wasi in docs

prtest:full

* benches: use wasi-common

* cfg-if around use of rustix::process because that doesnt exist on windows

* wasi-common: include tests, caught by verify-publish

* fix another bench

* exit requires wasmtime dep. caught by verify-publish.

show more ...

Switch to simpler fuel APIs (#7298)

In an effort to simplify the many fuel related APIs, simplify the
interface here to a single counter with get and set methods.
Additionally the async yield is red

Switch to simpler fuel APIs (#7298)

In an effort to simplify the many fuel related APIs, simplify the
interface here to a single counter with get and set methods.
Additionally the async yield is reduced to an interval of the total fuel
instead of injecting fuel, so it's easy to still reason about how much
fuel is left even with yielding turned on.

Internally this works by keeping two counters - one the VM uses to
increment towards 0 for fuel, the other to track how much is in
"reserve". Then when we're out of gas, we pull from the reserve to
refuel and continue. We use the reserve in two cases: one for overflow
of the fuel (which is an i64 and the API expresses fuel as u64) and the
other for async yieling, which then the yield interval acts as a cap to
how much we can refuel with.

This also means that `get_fuel` can return the full range of `u64`
before this change it could only return up to `i64::MAX`. This is
important because this PR is removing the functionality to track fuel
consumption, and this makes the API less error prone for embedders to
track consumption themselves.

Careful to note that the VM counter that is stored as `i64` can be
positive if an instruction "costs" multiple units of fuel when the fuel
ran out.

prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

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 build of `wasmtime-wasi-bench` (#6999)

Looks like this wasn't built on CI since it wasn't tested. Flag it as
testable which should build it on CI which should catch future errors
like this.

Remove the implementation of wasi-crypto (#6816)

* Remove the implementation of wasi-crypto

This commit is a follow-up to the discussion on #6732. This removes
Wasmtime's implementation of the wasi

Remove the implementation of wasi-crypto (#6816)

* Remove the implementation of wasi-crypto

This commit is a follow-up to the discussion on #6732. This removes
Wasmtime's implementation of the wasi-crypto proposal from in-tree along
with its various support in CI, configuration, etc. See the discussion
on #6732 for the full information but at a high level the main reasons
for removing the implementation at this time are:

* There is not currently an active maintainer of the Wasmtime
integration here for wasi-crypto.
* There are known issues with the code quality of the implementation
such as transmutes of guest-owned memory to `&'static mut [u8]` and
known unsafety in dependencies.
* The size and breadth of the dependency tree brings maintenance burden
and overhead to managing Wasmtime's dependency tree.

As mentioned on the issue this commit does not mean that Wasmtime
doesn't want to implement the wasi-crypto proposal. Instead the "tier 3"
status of wasi-crypto needs to be re-attained to be included back
in-tree, which would mean resolving the above issues.

Note that this commit is intentionally just after the 13.0.0 branch
point which means that this is slated for Wasmtime 14 to be released on
September 20.

* Remove some cfgs

* Remove wasi-crypto CI

show more ...

wasmtime bench-api build error when using --feature wasi-crypto (#6670) (#6671)

Fixing typo of wasmtime_wasi_nn -> wasmtime_wasi_crypto that was causing
a build error when building the bench-api wit

wasmtime bench-api build error when using --feature wasi-crypto (#6670) (#6671)

Fixing typo of wasmtime_wasi_nn -> wasmtime_wasi_crypto that was causing
a build error when building the bench-api with the wasi-crypto feature
enabled.

show more ...

Ability to disable cache after it's been configured on `Config` (#5542)

* Wasmtime: Add `Config::disable_cache`

* bench-api: Always disable the cache

* bench-api: Always get a `Config` from CL

Ability to disable cache after it's been configured on `Config` (#5542)

* Wasmtime: Add `Config::disable_cache`

* bench-api: Always disable the cache

* bench-api: Always get a `Config` from CLI flags

This commit fixes an issue that I ran into just now where benchmarking
one `*.so` with `--engine-flags` was giving wildly unexpected results
comparing to something without `--engine-flags`. The root cause here
appears to that when specifying `--engine-flags` the CLI parsing code is
used to create a `Config` and when omitted a `Config::new` instance is
created. The main difference between these is that for the CLI caching
is enabled by default and for `Config::new` it is not. Coupled with the
fact that caching doesn't really work for the `main` branch this ended
up giving wild results.

The fix here is to first always use the CLI parsing code to create a
`Config` to ensure that a config is consistently created. Next the
`--disable-cache` flag is unconditionally passed to the CLI parsing to
ensure that compilation actually happens.

Once applied this enables comparing an engine without flags and an
engine with flags which provides consistent results.

* Fix compile error

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

show more ...

Support fuel and epoch interruption in the benchmarking API (#5449)

When these engine flags are passed be sure to configure the store
appropriately to ensure that the wasm can actually run instead

Support fuel and epoch interruption in the benchmarking API (#5449)

When these engine flags are passed be sure to configure the store
appropriately to ensure that the wasm can actually run instead of
crashing immediately, enabling benchmarking comparisons between these
modes.

show more ...

Fix get_typed_fund extra param in benchmark (#5280)

Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)

* Return `anyhow::Error` from host functions instead of `Trap`

This commit refactors how errors are modeled w

Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)

* Return `anyhow::Error` from host functions instead of `Trap`

This commit refactors how errors are modeled when returned from host
functions and additionally refactors how custom errors work with `Trap`.
At a high level functions in Wasmtime that previously worked with
`Result<T, Trap>` now work with `Result<T>` instead where the error is
`anyhow::Error`. This includes functions such as:

* Host-defined functions in a `Linker<T>`
* `TypedFunc::call`
* Host-related callbacks like call hooks

Errors are now modeled primarily as `anyhow::Error` throughout Wasmtime.
This subsequently removes the need for `Trap` to have the ability to
represent all host-defined errors as it previously did. Consequently the
`From` implementations for any error into a `Trap` have been removed
here and the only embedder-defined way to create a `Trap` is to use
`Trap::new` with a custom string.

After this commit the distinction between a `Trap` and a host error is
the wasm backtrace that it contains. Previously all errors in host
functions would flow through a `Trap` and get a wasm backtrace attached
to them, but now this only happens if a `Trap` itself is created meaning
that arbitrary host-defined errors flowing from a host import to the
other side won't get backtraces attached. Some internals of Wasmtime
itself were updated or preserved to use `Trap::new` to capture a
backtrace where it seemed useful, such as when fuel runs out.

The main motivation for this commit is that it now enables hosts to
thread a concrete error type from a host function all the way through to
where a wasm function was invoked. Previously this could not be done
since the host error was wrapped in a `Trap` that didn't provide the
ability to get at the internals.

A consequence of this commit is that when a host error is returned that
isn't a `Trap` we'll capture a backtrace and then won't have a `Trap` to
attach it to. To avoid losing the contextual information this commit
uses the `Error::context` method to attach the backtrace as contextual
information to ensure that the backtrace is itself not lost.

This is a breaking change for likely all users of Wasmtime, but it's
hoped to be a relatively minor change to workaround. Most use cases can
likely change `-> Result<T, Trap>` to `-> Result<T>` and otherwise
explicit creation of a `Trap` is largely no longer necessary.

* Fix some doc links

* add some tests and make a backtrace type public (#55)

* Trap: avoid a trailing newline in the Display impl

which in turn ends up with three newlines between the end of the
backtrace and the `Caused by` in the anyhow Debug impl

* make BacktraceContext pub, and add tests showing downcasting behavior of anyhow::Error to traps or backtraces

* Remove now-unnecesary `Trap` downcasts in `Linker::module`

* Fix test output expectations

* Remove `Trap::i32_exit`

This commit removes special-handling in the `wasmtime::Trap` type for
the i32 exit code required by WASI. This is now instead modeled as a
specific `I32Exit` error type in the `wasmtime-wasi` crate which is
returned by the `proc_exit` hostcall. Embedders which previously tested
for i32 exits now downcast to the `I32Exit` value.

* Remove the `Trap::new` constructor

This commit removes the ability to create a trap with an arbitrary error
message. The purpose of this commit is to continue the prior trend of
leaning into the `anyhow::Error` type instead of trying to recreate it
with `Trap`. A subsequent simplification to `Trap` after this commit is
that `Trap` will simply be an `enum` of trap codes with no extra
information. This commit is doubly-motivated by the desire to always use
the new `BacktraceContext` type instead of sometimes using that and
sometimes using `Trap`.

Most of the changes here were around updating `Trap::new` calls to
`bail!` calls instead. Tests which assert particular error messages
additionally often needed to use the `:?` formatter instead of the `{}`
formatter because the prior formats the whole `anyhow::Error` and the
latter only formats the top-most error, which now contains the
backtrace.

* Merge `Trap` and `TrapCode`

With prior refactorings there's no more need for `Trap` to be opaque or
otherwise contain a backtrace. This commit parse down `Trap` to simply
an `enum` which was the old `TrapCode`. All various tests and such were
updated to handle this.

The main consequence of this commit is that all errors have a
`BacktraceContext` context attached to them. This unfortunately means
that the backtrace is printed first before the error message or trap
code, but given all the prior simplifications that seems worth it at
this time.

* Rename `BacktraceContext` to `WasmBacktrace`

This feels like a better name given how this has turned out, and
additionally this commit removes having both `WasmBacktrace` and
`BacktraceContext`.

* Soup up documentation for errors and traps

* Fix build of the C API

Co-authored-by: Pat Hickey <[email protected]>

show more ...

Fix wasmtime-bench-api build (#4956)

This fixes a compile-time error introduced in #4207. The `?` operator
doesn't work inside `Option::map` because it tries to return from the
inner closure, not

Fix wasmtime-bench-api build (#4956)

This fixes a compile-time error introduced in #4207. The `?` operator
doesn't work inside `Option::map` because it tries to return from the
inner closure, not the outer function.

Apparently our CI doesn't build wasmtime-bench-api so it didn't catch
this issue.

show more ...

bench-api: configure WASI modules based on passed flags (#4207)

* bench-api: configure WASI modules based on passed flags

When benchmarking in Sightglass, @brianjjones has found it necessary to

bench-api: configure WASI modules based on passed flags (#4207)

* bench-api: configure WASI modules based on passed flags

When benchmarking in Sightglass, @brianjjones has found it necessary to
enable the wasi-nn module. The current way to do so is to alter the
engine build script to pass `--features wasi-nn` so that this crate can
run code relying on these imports. This change allows the user to
instead pass the WASI modules using the engine flags added in #4096.
This could look something like the following in Sightglass:

```
sightglass-cli benchmark ... --engine-flags '--wasi-modules experimental-wasi-nn'
```

* fix: disable wasi-crypto as a default feature

show more ...

Fix unused result that is `#[must_use]` (#4663)

Fixes this compiler warning:

```
warning: unused return value of `Box::<T>::from_raw` that must be used
--> crates/bench-api/src/lib.rs:351:9

Fix unused result that is `#[must_use]` (#4663)

Fixes this compiler warning:

```
warning: unused return value of `Box::<T>::from_raw` that must be used
--> crates/bench-api/src/lib.rs:351:9
|
351 | Box::from_raw(state as *mut BenchState);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
```

show more ...

bench-api: configure execution with a flags string (#4096)

As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The eas

bench-api: configure execution with a flags string (#4096)

As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.

show more ...