Migrate fuzzing to `wasmtime::error` (#12263)

* Migrate fuzzing to `wasmtime::error`

* fix

Remove usage of `gen` as an identifier (#9958)

This commit is a start to some preparation for the Rust 2024 edition for
Wasmtime and this workspace. The `rust-2024-compatibility` lint group in
rustc

Remove usage of `gen` as an identifier (#9958)

This commit is a start to some preparation for the Rust 2024 edition for
Wasmtime and this workspace. The `rust-2024-compatibility` lint group in
rustc, currently off-by-default, is intended to assist with migrating
code to prepare for the 2024 edition. Some of those lints though are, in
my opinion, far too noisy to be turned on so this PR doesn't turn on the
whole group. Instead though I plan on enabling individual lints over
time in our `Cargo.toml` before the 2024 edition is enabled. This should
hopefully provide a relatively smooth and less churn-y path to enabling
the 2024 edition in the future.

The first lint enabled here in this commit is the `keyword_idents_2024`
lint which warns against usage of identifiers that will become keywords
in the 2024 edition. The only one affecting Wasmtime is the `gen`
identifier (soon to be keyword) and we had quite a few instances of it.
Where possible I've renamed to `generator` or `generate` or `generated`
but when used as methods from upstream crate traits (e.g.
`RngCore::gen`) we're forced to use `r#gen`. The `rand` crate will be
updated in 0.9.0 to avoid this keyword so this shouldn't be permanent.

show more ...

Update wasm-tools crates (#9336)

* Update wasm-tools crates

* WIT `float32` and `float64` are now hard errors (renamed to `f32` and
`f64`)
* Stack switching has been implemented in wasm-tools, bu

Update wasm-tools crates (#9336)

* Update wasm-tools crates

* WIT `float32` and `float64` are now hard errors (renamed to `f32` and
`f64`)
* Stack switching has been implemented in wasm-tools, but not Wasmtime.
* New shared-everything-threads component model intrinsics are not implemented

"Holes" for these new features in wasmparser are now present in Wasmtime
and panics shouldn't be hit because the new proposals aren't enabled in
the validator at this time.

* Fix fuzzer build

* Fix fuzzer tests

show more ...

Update the wasm-tools family of crates (#7921)

* Update the wasm-tools family of crates

Pulling in some updates to improve how WIT is managed in this
repository. No changes just yet, however, just

Update the wasm-tools family of crates (#7921)

* Update the wasm-tools family of crates

Pulling in some updates to improve how WIT is managed in this
repository. No changes just yet, however, just pulling in the updates
first.

* Fix tests

* Fix fuzzer build

show more ...

Update core dump generation in the cli to use wasm-encoder (#6306)

* Update coredump generation in the cli to use wasm_encoder

* Add deny.toml exception for wasm-encoder 0.25.0

* add missing newli

Update core dump generation in the cli to use wasm-encoder (#6306)

* Update coredump generation in the cli to use wasm_encoder

* Add deny.toml exception for wasm-encoder 0.25.0

* add missing newline

* update custom section in fuzzing crate

show more ...

Improve longevity for fuzzing corpus of wasm modules (#6322)

* Improve longevity for fuzzing corpus of wasm modules

This commit is an improvement to the longevity of Wasmtime's corpus of
fuzz input

Improve longevity for fuzzing corpus of wasm modules (#6322)

* Improve longevity for fuzzing corpus of wasm modules

This commit is an improvement to the longevity of Wasmtime's corpus of
fuzz inputs to the `instantiate` fuzzer. Currently the input to this
fuzzers is arbitrary binary data which is a "DNA" of sorts of what to
do. This DNA changes over time as we update the fuzzer and add
configuration options, for example. When this happens though the
meaning of all existing inputs in the corpus changes because they all
have slightly different meanings now. The goal of this commit is to
improve the usefulness of a historical corpus, with respect to the
WebAssembly modules generated, across changes to the DNA.

A custom mutator is now provided for the `instantiate` fuzzer. This
mutator will not only perform libfuzzer's default mutation for the input
but will additionally place an "envelope" around the fuzz input. Namely,
the fuzz input is encoded as a valid WebAssembly module where the actual
input to the fuzzer is a trailing custom section. When the fuzzer runs
over this input it will read the custom section, perform any
configuration generation necessary, and then use the envelope module as
the actual input to the fuzzer instead of whatever was generated from
the fuzz input. This means that when a future update is made to the DNA
of a module the interpretation of the fuzz input section will change but
the module in question will not change. This means that any interesting
shapes of modules with respect to instructions should be preserved over
time in theory.

Some consequences of this strategy, however, are:

* If the DNA changes then it's difficult to produce minor mutations of
the original module. This is because mutations generate a module based
on the new DNA which is likely much different than the preexisting
module. This mainly just means that libFuzzer will have to rediscover
how to mutate up into interesting shapes on DNA changes but it'll
still be able to retain all the existing interesting modules.
Additionally this can be mitigate with the integration of
`wasm-mutate` perhaps into these fuzzers as well.

* Protection is necessary against libFuzzer itself with respect to the
module. The existing fuzzers only expect valid modules to be created,
but libFuzzer can now create mutations which leave the trailing
section in place, meaning the module is no longer valid. One option is
to record a cryptographic hash in the fuzz input section of the
previous module, only using the module if the hashes match. This
approach will not work over time in the face of binary format changes,
however. For example the multi-memory proposal changed binary
encodings a year or so ago meaning that any previous fuzz-generated
cases would no longer be guaranteed to be valid. The strategy settled
by this PR is to pass a flag to the execution function indicating if
the module is "known valid" and gracefully handle error if it isn't
(for example if it's a prior test case).

I'll note that this new strategy of fuzzing is not applied to the
`differential` fuzzer. This could theoretically use the same strategy
but it relies much more strictly on being able to produce a module with
properties like NaN canonicalization, resource limits, fuel to limit
execution, etc. While it may be possible to integrate this with
`differential` in the future I figured it'd be better to start with the
`instantiate` fuzzer and go from there.

* Fix doc build

show more ...