Update wasm-tools crates (#10731)

* Update wasm-tools crates

Minor API changes, mostly just stubbing out support for
fixed-size-lists.

* Update vets

* Update some test expectations

Start using `#[expect]` instead of `#[allow]` (#9696)

* Start using `#[expect]` instead of `#[allow]`

In Rust 1.81, our new MSRV, a new feature was added to Rust to use
`#[expect]` to control lint

Start using `#[expect]` instead of `#[allow]` (#9696)

* Start using `#[expect]` instead of `#[allow]`

In Rust 1.81, our new MSRV, a new feature was added to Rust to use
`#[expect]` to control lint levels. This new lint annotation will
silence a lint but will itself cause a lint if it doesn't actually
silence anything. This is quite useful to ensure that annotations don't
get stale over time.

Another feature is the ability to use a `reason` directive on the
attribute with a string explaining why the attribute is there. This
string is then rendered in compiler messages if a warning or error
happens.

This commit migrates applies a few changes across the workspace:

* Some `#[allow]` are changed to `#[expect]` with a `reason`.
* Some `#[allow]` have a `reason` added if the lint conditionally fires
(mostly related to macros).
* Some `#[allow]` are removed since the lint doesn't actually fire.
* The workspace configures `clippy::allow_attributes_without_reason = 'warn'`
as a "ratchet" to prevent future regressions.
* Many crates are annotated to allow `allow_attributes_without_reason`
during this transitionary period.

The end-state is that all crates should use
`#[expect(..., reason = "...")]` for any lint that unconditionally fires
but is expected. The `#[allow(..., reason = "...")]` lint should be used
for conditionally firing lints, primarily in macro-related code.
The `allow_attributes_without_reason = 'warn'` level is intended to be
permanent but the transitionary
`#[expect(clippy::allow_attributes_without_reason)]` crate annotations
to go away over time.

* Fix adapter build

prtest:full

* Fix one-core build of icache coherence

* Use `allow` for missing_docs

Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't
fixed for our MSRV at this time.

* More MSRV compat

show more ...

Implement the wide-arithmetic proposal (#9403)

This commit implements the [wide-arithmetic] proposal in Wasmtime. This
is a pretty easy proposal to implement due to Cranelift already having
support

Implement the wide-arithmetic proposal (#9403)

This commit implements the [wide-arithmetic] proposal in Wasmtime. This
is a pretty easy proposal to implement due to Cranelift already having
support for all the various instructions. The features implemented here
are:

* Cranelift support for the four new instructions.
* A new `Config::wasm_wide_arithmetic` option.
* A new `-Wwide-arithmetic` CLI flag.
* A new `wasmtime_config_wasm_wide_arithmetic_set` C API function.
* Support for fuzzing this proposal
* Generation is implemented in `wasm-smith` .
* While it's off-by-default in `wasm-smith` it's enabled-by-default here.
* Differential execution is only possible against Wasmtime right now.
* Single-instruction module support was added for these new instructions.
* Tests for some simple cases plus randomly-generated tests.
* Example disassemblies for new instructions on Cranelift architectures.

[wide-arithmetic]: https://github.com/WebAssembly/wide-arithmetic

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 wasm-tools crates (#8019)

Keepin' up-to-date.

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

* Update the wasm-tools family of crates

Brings in support for validating gc instructions, but they're all left
disabled for now.

* Update fuzz test

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

* Update the wasm-tools family of crates

Brings in support for validating gc instructions, but they're all left
disabled for now.

* Update fuzz test case generation

* More test fixes, remove stray files

* More test fixes

* Rebase

show more ...

Update wasm-tools crates (#5130)

* Update wasm-tools crates

Mostly just a hygienic update, nothing major here

* Fix fuzz compile

* Fix test expectations

[fuzz] Add SIMD to single-instruction generator (#4778)

* [fuzz] Add SIMD to single-instruction generator

This change extends the single-instruction generator with most of the
SIMD instructions.

[fuzz] Add SIMD to single-instruction generator (#4778)

* [fuzz] Add SIMD to single-instruction generator

This change extends the single-instruction generator with most of the
SIMD instructions. Examples of instructions that were excluded are: all
memory-related instructions, any instruction with an immediate.

* [fuzz] Generate V128s with known values from each type

To better cover the fuzzing search space, `DiffValue` will generate
better known values for the `V128` type. First, it uses arbitrary data
to select a sub-type (e.g., `I8x16`, `F32x4`, etc.) and then it fills in
the bytes by generating biased values for each of the lanes.

* [fuzz] Canonicalize NaN values in SIMD lanes

This change ports the NaN canonicalization logic from `wasm-smith`
([here]) to the single-instruction generator.

[here]: https://github.com/bytecodealliance/wasm-tools/blob/6c127a6/crates/wasm-smith/src/core/code_builder.rs#L927

show more ...

Throw out fewer fuzz inputs with differential fuzzer (#4859)

* Throw out fewer fuzz inputs with differential fuzzer

Prior to this commit the differential fuzzer would generate a module and
then

Throw out fewer fuzz inputs with differential fuzzer (#4859)

* Throw out fewer fuzz inputs with differential fuzzer

Prior to this commit the differential fuzzer would generate a module and
then select an engine to execute the module against Wasmtime. This
meant, however, that the candidate list of engines were filtered against
the configuration used to generate the module to ensure that the
selected engine could run the generated module.

This commit inverts this logic and instead selects an engine first,
allowing the engine to then tweak the module configuration to ensure
that the generated module is compatible with the engine selected. This
means that fewer fuzz inputs are discarded because every fuzz input will
result in an engine being executed.

Internally the engine constructors have all been updated to update the
configuration to work instead of filtering the configuration. Some other
fixes were applied for the spec interpreter as well to work around #4852

* Fix tests

show more ...

[fuzz] Simplify macros used by single-instruction generator (#4774)

This removes the multiple macros used previously to describe the
WebAssembly instruction signatures and replaces them with a sing

[fuzz] Simplify macros used by single-instruction generator (#4774)

This removes the multiple macros used previously to describe the
WebAssembly instruction signatures and replaces them with a single
one--`inst!`.

show more ...

[fuzz] Add a meta-differential fuzz target (#4515)

* [fuzz] Add `Module` enum, refactor `ModuleConfig`

This change adds a way to create either a single-instruction module or a
regular (big) `was

[fuzz] Add a meta-differential fuzz target (#4515)

* [fuzz] Add `Module` enum, refactor `ModuleConfig`

This change adds a way to create either a single-instruction module or a
regular (big) `wasm-smith` module. It has some slight refactorings in
preparation for the use of this new code.

* [fuzz] Add `DiffValue` for differential evaluation

In order to evaluate functions with randomly-generated values, we needed
a common way to generate these values. Using the Wasmtime `Val` type is
not great because we would like to be able to implement various traits
on the new value type, e.g., to convert `Into` and `From` boxed values
of other engines we differentially fuzz against. This new type,
`DiffValue`, gives us a common ground for all the conversions and
comparisons between the other engine types.

* [fuzz] Add interface for differential engines

In order to randomly choose an engine to fuzz against, we expect all of
the engines to meet a common interface. The traits in this commit allow
us to instantiate a module from its binary form, evaluate exported
functions, and (possibly) hash the exported items of the instance.

This change has some missing pieces, though:
- the `wasm-spec-interpreter` needs some work to be able to create
instances, evaluate a function by name, and expose exported items
- the `v8` engine is not implemented yet due to the complexity of its
Rust lifetimes

* [fuzz] Use `ModuleFeatures` instead of existing configuration

When attempting to use both wasm-smith and single-instruction modules,
there is a mismatch in how we communicate what an engine must be able to
support. In the first case, we could use the `ModuleConfig`, a wrapper
for wasm-smith's `SwarmConfig`, but single-instruction modules do not
have a `SwarmConfig`--the many options simply don't apply. Here, we
instead add `ModuleFeatures` and adapt a `ModuleConfig` to that.
`ModuleFeatures` then becomes the way to communicate what features an
engine must support to evaluate functions in a module.

* [fuzz] Add a new fuzz target using the meta-differential oracle

This change adds the `differential_meta` target to the list of fuzz
targets. I expect that sometime soon this could replace the other
`differential*` targets, as it almost checks all the things those check.
The major missing piece is that currently it only chooses
single-instruction modules instead of also generating arbitrary modules
using `wasm-smith`.

Also, this change adds the concept of an ignorable error: some
differential engines will choke with certain inputs (e.g., `wasmi` might
have an old opcode mapping) which we do not want to flag as fuzz bugs.
Here we wrap those errors in `DiffIgnoreError` and then use a new helper
trait, `DiffIgnorable`, to downcast and inspect the `anyhow` error to
only panic on non-ignorable errors; the ignorable errors are converted
to one of the `arbitrary::Error` variants, which we already ignore.

* [fuzz] Compare `DiffValue` NaNs more leniently

Because arithmetic NaNs can contain arbitrary payload bits, checking
that two differential executions should produce the same result should
relax the comparison of the `F32` and `F64` types (and eventually `V128`
as well... TODO). This change adds several considerations, however, so
that in the future we make the comparison a bit stricter, e.g., re:
canonical NaNs. This change, however, just matches the current logic
used by other fuzz targets.

* review: allow hashing mutate the instance state

@alexcrichton requested that the interface be adapted to accommodate
Wasmtime's API, in which even reading from an instance could trigger
mutation of the store.

* review: refactor where configurations are made compatible

See @alexcrichton's
[suggestion](https://github.com/bytecodealliance/wasmtime/pull/4515#discussion_r928974376).

* review: convert `DiffValueType` using `TryFrom`

See @alexcrichton's
[comment](https://github.com/bytecodealliance/wasmtime/pull/4515#discussion_r928962394).

* review: adapt target implementation to Wasmtime-specific RHS

This change is joint work with @alexcrichton to adapt the structure of
the fuzz target to his comments
[here](https://github.com/bytecodealliance/wasmtime/pull/4515#pullrequestreview-1073247791).

This change:
- removes `ModuleFeatures` and the `Module` enum (for big and small
modules)
- upgrades `SingleInstModule` to filter out cases that are not valid for
a given `ModuleConfig`
- adds `DiffEngine::name()`
- constructs each `DiffEngine` using a `ModuleConfig`, eliminating
`DiffIgnoreError` completely
- prints an execution rate to the `differential_meta` target

Still TODO:
- `get_exported_function_signatures` could be re-written in terms of the
Wasmtime API instead `wasmparser`
- the fuzzer crashes eventually, we think due to the signal handler
interference between OCaml and Wasmtime
- the spec interpreter has several cases that we skip for now but could
be fuzzed with further work

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

* fix: avoid SIGSEGV by explicitly initializing OCaml runtime first

* review: use Wasmtime's API to retrieve exported functions

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

show more ...

[fuzz] Remove unnecessary allocation (#4689)

This resolves a comment @jameysharp made in a previous PR.

[fuzz] Fix issues with single-inst module generator (#4674)

* [fuzz] Fix signature of `i64.extend32_s` single-instruction test

This single-instruction test incorrectly attempted to convert an `i3

[fuzz] Fix issues with single-inst module generator (#4674)

* [fuzz] Fix signature of `i64.extend32_s` single-instruction test

This single-instruction test incorrectly attempted to convert an `i32`
to an `i64`; the correct signature is `i64 -> i64`. See the [WebAssembly
specification](https://webassembly.github.io/spec/core/bikeshed/#a7-index-of-instructions).

* [fuzz] Fix typo in single-instruction function generator

Previously, the `unary!` macro created functions that used two operands
instead of the expected one.

show more ...

fuzz: add a single instruction module generator (#4409)

* fuzz: add a single instruction module generator

As proposed by @cfallin in #3251, this change adds a way to generate a
Wasm module for a

fuzz: add a single instruction module generator (#4409)

* fuzz: add a single instruction module generator

As proposed by @cfallin in #3251, this change adds a way to generate a
Wasm module for a single instruction. It captures the necessary
parameter and result types so that fuzzing can not only choose which
instruction to check but also generate values to pass to the
instruction. Not all instructions are available yet, but a significant
portion of scalar instructions are implemented in this change.

This does not wire the generator up to any fuzz targets.

* review: use raw string in test

* review: remove once_cell, use slices

* review: refactor macros to use valtype!

* review: avoid cloning when choosing a SingleInstModule

show more ...