Changes in single_inst_module.rs

e682be4e - Update wasm-tools crates (#10731)

Mon, 05 May 2025 20:47:11 +0000

Update wasm-tools crates (#10731)* Update wasm-tools cratesMinor API changes, mostly just stubbing out support forfixed-size-lists.* Update vets* Update some test expectations List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Mon, 02 Dec 2024 17:19:20 +0000

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 willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.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 firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

72ded108 - Implement the wide-arithmetic proposal (#9403)

Tue, 08 Oct 2024 21:51:40 +0000

Implement the wide-arithmetic proposal (#9403)This commit implements the [wide-arithmetic] proposal in Wasmtime. Thisis a pretty easy proposal to implement due to Cranelift already havingsupport for all the various instructions. The features implemented hereare:* 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 List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

6844ed1a - Update wasm-tools crates (#9336)

Mon, 30 Sep 2024 19:35:24 +0000

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 Wasmtimeand panics shouldn't be hit because the new proposals aren't enabled inthe validator at this time.* Fix fuzzer build* Fix fuzzer tests List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

888bd112 - Update wasm-tools crates (#8019)

Wed, 28 Feb 2024 19:52:17 +0000

Update wasm-tools crates (#8019)Keepin' up-to-date. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Wed, 10 Jan 2024 16:19:14 +0000

Update the wasm-tools family of crates (#7764)* Update the wasm-tools family of cratesBrings in support for validating gc instructions, but they're all leftdisabled for now.* Update fuzz test case generation* More test fixes, remove stray files* More test fixes* Rebase List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

bc3285e8 - Update wasm-tools crates (#5130)

Wed, 26 Oct 2022 18:29:10 +0000

Update wasm-tools crates (#5130)* Update wasm-tools crates Mostly just a hygienic update, nothing major here * Fix fuzz compile * Fix test expectations List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Tue, 06 Sep 2022 21:54:39 +0000

[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 List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Tue, 06 Sep 2022 17:41:23 +0000

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 List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Wed, 24 Aug 2022 20:10:12 +0000

[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!`. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Fri, 19 Aug 2022 00:22:58 +0000

[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 * fix: avoid SIGSEGV by explicitly initializing OCaml runtime first * review: use Wasmtime's API to retrieve exported functions Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

c4fd6a95 - [fuzz] Remove unnecessary allocation (#4689)

Thu, 11 Aug 2022 19:26:33 +0000

[fuzz] Remove unnecessary allocation (#4689)This resolves a comment @jameysharp made in a previous PR. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Wed, 10 Aug 2022 16:47:02 +0000

[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. List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs

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

Thu, 07 Jul 2022 22:50:59 +0000

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 List of files: /wasmtime-44.0.1/crates/fuzzing/src/generators/single_inst_module.rs