Introduce `wasmtime_environ::collections::{OomArc, OomBox}` (#12361)

* Introduce `wasmtime_environ::collections::{OomArc, OomBox}`

These types mirror their `std`/`alloc` counterparts, but only prov

Introduce `wasmtime_environ::collections::{OomArc, OomBox}` (#12361)

* Introduce `wasmtime_environ::collections::{OomArc, OomBox}`

These types mirror their `std`/`alloc` counterparts, but only provide fallible
constructors and properly handle OOM by returning `Err(OutOfMemory)`.

Note that stable Rust doesn't actually give us any method to build fallible
allocation for `Arc<T>`, and we do not wish to fork `Arc<T>` since it is full of
very subtle unsafe code, so `OomArc::new` is only actually fallible in practice
when using nightly Rust and setting `RUSTFLAGS="--cfg arc_try_new"` during the
build. We use a custom `cfg`, rather than a cargo feature, so that `cargo test
--all-features --workspace` (which is morally what CI does) continues to Just
Work in the workspace, same as we do for e.g. Pulley's usage of the nightly Rust
tail calls feature.

Part of https://github.com/bytecodealliance/wasmtime/issues/12069

* Avoid unused import warning in certain build configs

* Remove `out_of_line_slow_path!` macro

* Use extension traits for fallible `Arc<T>` and `Box<T>` allocation

Instead of defining new wrapper types around them.

* Fix example in docs

show more ...

Consolidate "util" crates for testing (#10423)

* Consolidate "util" crates for testing

This commit consolidates all of the existing crates we have for testing
into a smaller set of crates. Specific

Consolidate "util" crates for testing (#10423)

* Consolidate "util" crates for testing

This commit consolidates all of the existing crates we have for testing
into a smaller set of crates. Specifically:

* `crates/misc/component-fuzz-util` => `wasmtime-test-util` + `component-fuzz`
feature
* `crates/misc/component-test-util` => `wasmtime-test-util` + `component`
feature
* `crates/wast-util` => `wasmtime-test-util` + `wast` feature
* `crates/misc/component-macro-test` => `wasmtime-test-macros`

The goal is to have one location we put various test helpers/macros
rather than our current organically-grown many locations. This is
inspired by the test failure on #10405 where I'd like to refactor more
infrastructure to a "test util" location but it wasn't clear where to
put it so I wanted to do this refactoring first.

* Remove unused file

show more ...

Fix minor wast fuzzing issues (#9764)

* Sort tests by name to ensure that a reproduction on one machine works
on another.
* Relax the error message matching to be a bit more lenient with paths.

Improve fuzzing of `*.wast` tests (#9587)

* Improve fuzzing of `*.wast` tests

Currently we have a fuzzer which is tasked with running `*.wast` tests
with fuzz-generated configurations. This asserts

Improve fuzzing of `*.wast` tests (#9587)

* Improve fuzzing of `*.wast` tests

Currently we have a fuzzer which is tasked with running `*.wast` tests
with fuzz-generated configurations. This asserts that we at least
satisfy all basic wasm semantics regardless of how various knobs in
`Config` are turned (modulo limits to resources). The current fuzzing
though is not comprehensive in that it doesn't include all the spec
tests that we pass from all proposals. This runs the risk of we don't
actually fuzz anything until the spec tests are merged upstream, which
can take a significant amount of time.

This commit refactors the `*.wast`-management infrastructure to share
test discovery and feature calculation between `tests/wast.rs` and
fuzzing. This new support crate centralizes limits and discovery for
both to use. Additionally fuzzing is updated to no longer throw out test
cases if configuration isn't applicable but instead clamp configuration
to the minimum required values (e.g. features + resource limits). This
means that we should now be fuzzing all spec tests that pass in all
configurations.

This new fuzzer discovered a few minor issues with the GC proposal
implementation, for example, such as:

* Some instructions were translated using trapping methods directly on
`FunctionBuilder` rather than `FuncEnvironment` meaning they didn't
properly handle `signals-based-traps` configuration.

* Fuel handling for `return_call_ref` wasn't correct because it was
accidentally omitted from the list of return-call instructions that
need special treatment.

* Add some manifest metadata

show more ...

Enforce `uninlined_format_args` for the workspace (#9065)

* Enforce `uninlined_format_args` for the workspace

* fix: failing `Monolith Checks` job

* fix: formatting

Run all `*.wast` tests in fuzzing (#8121)

* Run all `*.wast` tests in fuzzing

Currently we have a `spectest` fuzzer which uses fuzz input to generate
an arbitrary configuration for Wasmtime and the

Run all `*.wast` tests in fuzzing (#8121)

* Run all `*.wast` tests in fuzzing

Currently we have a `spectest` fuzzer which uses fuzz input to generate
an arbitrary configuration for Wasmtime and then executes the spec test.
This ensures that no matter the configuration Wasmtime can pass spec
tests. This commit expands this testing to include all `*.wast` tests we
have in this repository. While we don't have a ton we still have some
significant ones like in #8118 which will only reproduce when turning
knobs on CPU features.

* Fix CLI build

* Fix wast testing

show more ...

Actually make spectest fuzzing deterministic

Turns out #2106 missed the actual sorting operation. Silly me!

Make spectest fuzzing more deterministic

Currently spectest fuzzing indexes into a compile-time-created array of
strings which is the list of input files, but the order of this array is
dependent on

Make spectest fuzzing more deterministic

Currently spectest fuzzing indexes into a compile-time-created array of
strings which is the list of input files, but the order of this array is
dependent on the filesystem that we're reading from. This means that
inputs from oss-fuzz may not be easily reproducible locally because
files could be read in different orders, so indexes could be distinct.

This commit instead reads the directory paths, then sorts them, then
includes them for testing. That way fuzz inputs at a specific commit
should be consistent.

show more ...

Add a spec test fuzzer for Config (#1509)

* Add a spec test fuzzer for Config

This commit adds a new fuzzer which is intended to run on oss-fuzz. This
fuzzer creates and arbitrary `Config` which

Add a spec test fuzzer for Config (#1509)

* Add a spec test fuzzer for Config

This commit adds a new fuzzer which is intended to run on oss-fuzz. This
fuzzer creates and arbitrary `Config` which *should* pass spec tests and
then asserts that it does so. The goal here is to weed out any
accidental bugs in global configuration which could cause
non-spec-compliant behavior.

* Move implementation to `fuzzing` crate

show more ...