Changes in build.rs

72e909c4 - Migrate fuzzing to `wasmtime::error` (#12269)

Wed, 07 Jan 2026 22:29:30 +0000

Migrate fuzzing to `wasmtime::error` (#12269) List of files: /wasmtime-44.0.1/fuzz/build.rs

19d9a4ae - Set minimum stacks/instance size in the component-api fuzzer too (#12080)

Mon, 24 Nov 2025 19:00:43 +0000

Set minimum stacks/instance size in the component-api fuzzer too (#12080)Similar to other settings there needs to be a minimum when the poolingallocator is configured to actually be able to run modules. List of files: /wasmtime-44.0.1/fuzz/build.rs

5730c760 - Improve `Config`-related coverage of `component_api` (#12049)

Fri, 21 Nov 2025 17:04:17 +0000

Improve `Config`-related coverage of `component_api` (#12049)This commit improves the preexisting `component_api` fuzz target to usearbitrary `Config` data. This, for example, helps exercise Pulley inaddition to native. In general this also helps stress and ensure that noconfig knobs are accidentally breaking ABI assumptions. List of files: /wasmtime-44.0.1/fuzz/build.rs

0b9ff9bf - Add async to the component_api fuzzer (#12047)

Wed, 19 Nov 2025 20:51:51 +0000

Add async to the component_api fuzzer (#12047)This commit extends the preexisting `component_api` fuzzer in Wasmtimeto support `async`. This required a fair bit of refactoring to how thefuzzer worked but the basic idea remains the same. This fuzzergenerates:* An arbitrary component-model type signature (minus resources/futures/streams)* A component which imports a function of this signature from the host and exports a function of this signature to the host.* Internally the export is implemented with a component `caller` that imports/exports this function signature.* The `caller` component is instantiated with a `callee` component that imports/exports this function signature.* The `callee` component is instantiated with the host.In essence a component model value is threaded into a component, toanother composed component, then back out to the host. The return valuethen makes its way back through the same channel. The fuzz test ensuresthat the parameters received in the host import are the same as thosepassed to the export. Additionally the return value of the export isensured to be the same as the one that the host import returned. Inessence this is testing ABI handling in Wasmtime to ensure thatcomposition works correctly in addition to lifting/lowering code.This fuzzer additionally has a "static" and "dynamic" mode where, atcompile time, N components are generated with different signatures anduse the "typed" APIs of Wasmtime. For "dynamic" `Val` is used to testand arbitrary components are generated at fuzz-time. The fuzzer finallyexecutes this roundtrip in a loop multiple times in one fuzz test caseto test different runtime-shapes of values in addition tocompile-time-shapes of values.The main addition in this commit is to extend all of this with the asyncABI. The following knobs were added and implemented:* The function type used for the root component export, the function between the composed components, and the function imported from the host all have the ability to be an `async` function type now.* The lifts/lowers, in all locations, can be configured with the various ABIs supported (e.g. sync, async-callback, or async-stackful for lifts, and sync/async for lowers).* Like before the string encoding can be varied between the components as well.This is intended to stress combining different flavors of ABI withdifferent behaviors to ensure that all the various paths throughoutWasmtime and such are hit. The goal of this fuzzer is to stress ABIlifting/lowering, so this is not handling much related to async eventscheduling (that's for a future fuzzer).In a follow-up commit I hope to extend this fuzzer with some async eventscheduling nonetheless. For example the fuzzer will generate an asyncyield point before/after calling `task.return` or before/after callingthe host import. That is intended to stress `first_poll`-vs-not behavioras it relates to ABI handling. None of that is yet implemented and forthis fuzzer async calls are assumed to always succeed immediately for now. List of files: /wasmtime-44.0.1/fuzz/build.rs

75c86826 - Enable `allow_attributes_without_reason` in fuzzer (#10961)

Fri, 06 Jun 2025 20:08:05 +0000

Enable `allow_attributes_without_reason` in fuzzer (#10961)This was a holdover from the initial migration, no reason to exclude thefuzzer any more. List of files: /wasmtime-44.0.1/fuzz/build.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/fuzz/build.rs

ca7081a2 - Consolidate "util" crates for testing (#10423)

Thu, 20 Mar 2025 15:08:47 +0000

Consolidate "util" crates for testing (#10423)* Consolidate "util" crates for testingThis commit consolidates all of the existing crates we have for testinginto 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/macrosrather than our current organically-grown many locations. This isinspired by the test failure on #10405 where I'd like to refactor moreinfrastructure to a "test util" location but it wasn't clear where toput it so I wanted to do this refactoring first.* Remove unused file List of files: /wasmtime-44.0.1/fuzz/build.rs

287e8fb5 - Update wasm-tools crates to 226 (#10235)

Wed, 19 Feb 2025 20:38:07 +0000

Update wasm-tools crates to 226 (#10235)* Update wasm-tools crates to 226This commit updates the wasm-tools crates to the 226 track of versions.The most notable change here is the removal and refactoring withinwasm-tools of support for multiple and named returns in the componentmodel along with the support for 33+ flags in the `flags` type. This hasbeen gated for some time now and it's just now being removed now thatit's been awhile an no issues have been raised.prtest:full* Fix some issues from CI* Fix benchmarks* Switch to crates.io-based crates List of files: /wasmtime-44.0.1/fuzz/build.rs

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

Thu, 09 Jan 2025 16:47:51 +0000

Remove usage of `gen` as an identifier (#9958)This commit is a start to some preparation for the Rust 2024 edition forWasmtime and this workspace. The `rust-2024-compatibility` lint group inrustc, currently off-by-default, is intended to assist with migratingcode to prepare for the 2024 edition. Some of those lints though are, inmy opinion, far too noisy to be turned on so this PR doesn't turn on thewhole group. Instead though I plan on enabling individual lints overtime in our `Cargo.toml` before the 2024 edition is enabled. This shouldhopefully provide a relatively smooth and less churn-y path to enablingthe 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 keywordsin 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 beupdated in 0.9.0 to avoid this keyword so this shouldn't be permanent. List of files: /wasmtime-44.0.1/fuzz/build.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/fuzz/build.rs

9733e7d5 - Fix the component_api fuzzer (#6410)

Fri, 19 May 2023 05:49:06 +0000

Fix the component_api fuzzer (#6410)This fuzz target was accidentally broken by #6378 and I forgot to updatethis fuzz target. Namely all the generated types now need names tosatisfy possible restrictions depending on the structure. For simplicityeverything is given a name to avoid having to special case some vsothers which isn't the purpose of this fuzz target. List of files: /wasmtime-44.0.1/fuzz/build.rs

b1d63f01 - Update test case generation for component_api fuzzer (#6315)

Mon, 01 May 2023 15:44:12 +0000

Update test case generation for component_api fuzzer (#6315)This commit updates the test case generation for the `component_api`fuzzer to prepare for an update to the `arbitrary` crate. The currentalgorithm, with the latest `arbitrary` crate, generates a 20MB sourcefile which is a bit egregious. The goal here was to get that undercontrol by altering the parameters of test case generation andadditionally changing the structure of what's generated.The new strategy is to have a limited set of "type fuel" which isconsumed as a type is generated. This bounds the maximal size of a typein addition to its depth as prior. Additionally a fixed set of types aregenerated first and then test cases select from these types as opposedto test cases always generating types for themselves. Coupled togetherthis brings the size of the generated file back into the 200K range asit was before. List of files: /wasmtime-44.0.1/fuzz/build.rs

dd81e5a6 - Don't let fuzz targets import `arbitrary` directly (#4806)

Mon, 29 Aug 2022 23:06:41 +0000

Don't let fuzz targets import `arbitrary` directly (#4806)The version of the `arbitrary` crate used in fuzz targets needs to be the same as the version used in `libfuzzer-sys`. That's why the latter crate re-exports the former. But we need to make sure to consistently use the re-exported version. That's most easily done if that's the only version we have available. However, `fuzz/Cargo.toml` declared a direct dependency on `arbitrary`, making it available for import, and leading to that version being used in a couple places. There were two copies of `arbitrary` built before, even though they were the same version: one with the `derive` feature turned on, through the direct dependency, and one with it turned off when imported through `libfuzzer-sys`. So I haven't specifically tested this but fuzzer builds might be slightly faster now. I have not removed the build-dep on `arbitrary`, because `build.rs` is not invoked by libFuzzer and so it doesn't matter what version of `arbitrary` it uses. Our other crates, like `cranelift-fuzzgen` and `wasmtime-fuzzing`, can still accidentally use a different version of `arbitrary` than the fuzz targets which rely on them. This commit only fixes the direct cases within `fuzz/**`. List of files: /wasmtime-44.0.1/fuzz/build.rs

57dca934 - Upgrade wasm-tools crates, namely the component model (#4715)

Wed, 17 Aug 2022 16:17:34 +0000

Upgrade wasm-tools crates, namely the component model (#4715)* Upgrade wasm-tools crates, namely the component model This commit pulls in the latest versions of all of the `wasm-tools` family of crates. There were two major changes that happened in `wasm-tools` in the meantime: * bytecodealliance/wasm-tools#697 - this commit introduced a new API for more efficiently reading binary operators from a wasm binary. The old `Operator`-based reading was left in place, however, and continues to be what Wasmtime uses. I hope to update Wasmtime in a future PR to use this new API, but for now the biggest change is... * bytecodealliance/wasm-tools#703 - this commit was a major update to the component model AST. This commit almost entirely deals with the fallout of this change. The changes made to the component model were: 1. The `unit` type no longer exists. This was generally a simple change where the `Unit` case in a few different locations were all removed. 2. The `expected` type was renamed to `result`. This similarly was relatively lightweight and mostly just a renaming on the surface. I took this opportunity to rename `val::Result` to `val::ResultVal` and `types::Result` to `types::ResultType` to avoid clashing with the standard library types. The `Option`-based types were handled with this as well. 3. The payload type of `variant` and `result` types are now optional. This affected many locations that calculate flat type representations, ABI information, etc. The `#[derive(ComponentType)]` macro now specifically handles Rust-defined `enum` types which have no payload to the equivalent in the component model. 4. Functions can now return multiple parameters. This changed the signature of invoking component functions because the return value is now bound by `ComponentNamedList` (renamed from `ComponentParams`). This had a large effect in the tests, fuzz test case generation, etc. 5. Function types with 2-or-more parameters/results must uniquely name all parameters/results. This mostly affected the text format used throughout the tests. I haven't added specifically new tests for multi-return but I changed a number of tests to use it. Additionally I've updated the fuzzers to all exercise multi-return as well so I think we should get some good coverage with that. * Update version numbers * Use crates.io List of files: /wasmtime-44.0.1/fuzz/build.rs

866ec466 - Implement roundtrip fuzzing of component adapters (#4640)

Mon, 08 Aug 2022 18:01:45 +0000

Implement roundtrip fuzzing of component adapters (#4640)* Improve the `component_api` fuzzer on a few dimensions * Update the generated component to use an adapter module. This involves two core wasm instances communicating with each other to test that data flows through everything correctly. The intention here is to fuzz the fused adapter compiler. String encoding options have been plumbed here to exercise differences in string encodings. * Use `Cow<'static, ...>` and `static` declarations for each static test case to try to cut down on rustc codegen time. * Add `Copy` to derivation of fuzzed enums to make `derive(Clone)` smaller. * Use `Store>` to try to cut down on codegen by monomorphizing fewer `Store` implementation. * Add debug logging to print out what's flowing in and what's flowing out for debugging failures. * Improve `Debug` representation of dynamic value types to more closely match their Rust counterparts. * Fix a variant issue with adapter trampolines Previously the offset of the payload was calculated as the discriminant aligned up to the alignment of a singular case, but instead this needs to be aligned up to the alignment of all cases to ensure all cases start at the same location. * Fix a copy/paste error when copying masked integers A 32-bit load was actually doing a 16-bit load by accident since it was copied from the 16-bit load-and-mask case. * Fix f32/i64 conversions in adapter modules The adapter previously erroneously converted the f32 to f64 and then to i64, where instead it should go from f32 to i32 to i64. * Fix zero-sized flags in adapter modules This commit corrects the size calculation for zero-sized flags in adapter modules. cc #4592 * Fix a variant size calculation bug in adapters This fixes the same issue found with variants during normal host-side fuzzing earlier where the size of a variant needs to align up the summation of the discriminant and the maximum case size. * Implement memory growth in libc bump realloc Some fuzz-generated test cases are copying lists large enough to exceed one page of memory so bake in a `memory.grow` to the bump allocator as well. * Avoid adapters of exponential size This commit is an attempt to avoid adapters being exponentially sized with respect to the type hierarchy of the input. Previously all adaptation was done inline within each adapter which meant that if something was structured as `tuple` the translation of `T` would be inlined N times. For very deeply nested types this can quickly create an exponentially sized adapter with types of the form: (type $t0 (list u8)) (type $t1 (tuple $t0 $t0)) (type $t2 (tuple $t1 $t1)) (type $t3 (tuple $t2 $t2)) ;; ... where the translation of `t4` has 8 different copies of translating `t0`. This commit changes the translation of types through memory to almost always go through a helper function. The hope here is that it doesn't lose too much performance because types already reside in memory. This can still lead to exponentially sized adapter modules to a lesser degree where if the translation all happens on the "stack", e.g. via `variant`s and their flat representation then many copies of one translation could still be made. For now this commit at least gets the problem under control for fuzzing where fuzzing doesn't trivially find type hierarchies that take over a minute to codegen the adapter module. One of the main tricky parts of this implementation is that when a function is generated the index that it will be placed at in the final module is not known at that time. To solve this the encoded form of the `Call` instruction is saved in a relocation-style format where the `Call` isn't encoded but instead saved into a different area for encoding later. When the entire adapter module is encoded to wasm these pseudo-`Call` instructions are encoded as real instructions at that time. * Fix some memory64 issues with string encodings Introduced just before #4623 I had a few mistakes related to 64-bit memories and mixing 32/64-bit memories. * Actually insert into the `translate_mem_funcs` map This... was the whole point of having the map! * Assert memory growth succeeds in bump allocator List of files: /wasmtime-44.0.1/fuzz/build.rs

ed8908ef - implement fuzzing for component types (#4537)

Thu, 04 Aug 2022 17:02:55 +0000

implement fuzzing for component types (#4537)This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/fuzz/build.rs