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

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

Similar to other settings there needs to be a minimum when the pooling
allocator is configured to actually be able to run mo

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

Similar to other settings there needs to be a minimum when the pooling
allocator is configured to actually be able to run modules.

show more ...

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

This commit improves the preexisting `component_api` fuzz target to use
arbitrary `Config` data. This, for example, helps exercise Pulle

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

This commit improves the preexisting `component_api` fuzz target to use
arbitrary `Config` data. This, for example, helps exercise Pulley in
addition to native. In general this also helps stress and ensure that no
config knobs are accidentally breaking ABI assumptions.

show more ...

Add async to the component_api fuzzer (#12047)

This commit extends the preexisting `component_api` fuzzer in Wasmtime
to support `async`. This required a fair bit of refactoring to how the
fuzzer wo

Add async to the component_api fuzzer (#12047)

This commit extends the preexisting `component_api` fuzzer in Wasmtime
to support `async`. This required a fair bit of refactoring to how the
fuzzer worked but the basic idea remains the same. This fuzzer
generates:

* 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, to
another composed component, then back out to the host. The return value
then makes its way back through the same channel. The fuzz test ensures
that the parameters received in the host import are the same as those
passed to the export. Additionally the return value of the export is
ensured to be the same as the one that the host import returned. In
essence this is testing ABI handling in Wasmtime to ensure that
composition works correctly in addition to lifting/lowering code.

This fuzzer additionally has a "static" and "dynamic" mode where, at
compile time, N components are generated with different signatures and
use the "typed" APIs of Wasmtime. For "dynamic" `Val` is used to test
and arbitrary components are generated at fuzz-time. The fuzzer finally
executes this roundtrip in a loop multiple times in one fuzz test case
to test different runtime-shapes of values in addition to
compile-time-shapes of values.

The main addition in this commit is to extend all of this with the async
ABI. 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 with
different behaviors to ensure that all the various paths throughout
Wasmtime and such are hit. The goal of this fuzzer is to stress ABI
lifting/lowering, so this is not handling much related to async event
scheduling (that's for a future fuzzer).

In a follow-up commit I hope to extend this fuzzer with some async event
scheduling nonetheless. For example the fuzzer will generate an async
yield point before/after calling `task.return` or before/after calling
the host import. That is intended to stress `first_poll`-vs-not behavior
as it relates to ABI handling. None of that is yet implemented and for
this fuzzer async calls are assumed to always succeed immediately for now.

show more ...

Enable `allow_attributes_without_reason` in fuzzer (#10961)

This was a holdover from the initial migration, no reason to exclude the
fuzzer any more.

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

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 ...

Update wasm-tools crates to 226 (#10235)

* Update wasm-tools crates to 226

This commit updates the wasm-tools crates to the 226 track of versions.
The most notable change here is the removal and re

Update wasm-tools crates to 226 (#10235)

* Update wasm-tools crates to 226

This commit updates the wasm-tools crates to the 226 track of versions.
The most notable change here is the removal and refactoring within
wasm-tools of support for multiple and named returns in the component
model along with the support for 33+ flags in the `flags` type. This has
been gated for some time now and it's just now being removed now that
it's been awhile an no issues have been raised.

prtest:full

* Fix some issues from CI

* Fix benchmarks

* Switch to crates.io-based crates

show more ...

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 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 usag

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 MIRI

prtest: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

show more ...

Fix the component_api fuzzer (#6410)

This fuzz target was accidentally broken by #6378 and I forgot to update
this fuzz target. Namely all the generated types now need names to
satisfy possible rest

Fix the component_api fuzzer (#6410)

This fuzz target was accidentally broken by #6378 and I forgot to update
this fuzz target. Namely all the generated types now need names to
satisfy possible restrictions depending on the structure. For simplicity
everything is given a name to avoid having to special case some vs
others which isn't the purpose of this fuzz target.

show more ...

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 curren

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 current
algorithm, with the latest `arbitrary` crate, generates a 20MB source
file which is a bit egregious. The goal here was to get that under
control by altering the parameters of test case generation and
additionally changing the structure of what's generated.

The new strategy is to have a limited set of "type fuel" which is
consumed as a type is generated. This bounds the maximal size of a type
in addition to its depth as prior. Additionally a fixed set of types are
generated first and then test cases select from these types as opposed
to test cases always generating types for themselves. Coupled together
this brings the size of the generated file back into the 200K range as
it was before.

show more ...

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 latt

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/**`.

show more ...

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

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

show more ...

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

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<Box<dyn Any>>` to try to cut down on codegen by
monomorphizing fewer `Store<T>` 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<T, T, T, T, ...>` 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

show more ...

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 ty

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 <[email protected]>

show more ...