fix: correct various typos (#12807)Signed-off-by: Ho Kim <[email protected]>
Automatically handle `async` in `#[wasmtime_test]` (#12405)Remove the need to also specify `with = "#[tokio::test]"` and do thatautomatically.
WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try
WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn't support the host at all then there's noneed to run it. Actually running it could misinterpret `CraneliftNative`as "run with pulley" otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton <[email protected]>
show more ...
Simplify some conditional testing logic for Winch (#11166)* Simplify some conditional testing logic for WinchRun all tests on all platforms in `#[wasmtime_test]` for Winch without`#[cfg]` and u
Simplify some conditional testing logic for Winch (#11166)* Simplify some conditional testing logic for WinchRun all tests on all platforms in `#[wasmtime_test]` for Winch without`#[cfg]` and use the result of `should_fail` to determine whether itshould fail or not (e.g. still expect failure on riscv64/s390x/etc).* Ignore non-Pulley tests on Miri
winch(aarch64) Run integration tests in winch-aarch64 (#11031)* winch(aarch64) Run integration tests in winch-aarch64This commit closeshttps://github.com/bytecodealliance/wasmtime/issues/8321W
winch(aarch64) Run integration tests in winch-aarch64 (#11031)* winch(aarch64) Run integration tests in winch-aarch64This commit closeshttps://github.com/bytecodealliance/wasmtime/issues/8321With https://github.com/bytecodealliance/wasmtime/pull/11013, Winchpasses all spec tests for Core Wasm on Aarch64.* Run `cargo fmt`* Add an `integration` option to `TestConfig``wast::TestConfig` is shared across spec tests and integration tests,this commits adds a flag to identify if the config is for integrationtest purposes making it easier to contextually decide if tests areexpected to fail or pass depending on the Wasm configuration options.* Use `spec_test` instead of `integration`To better differentiate spec tests from integration tests* Ensure only aarch64 / x64 when testing Winch* Revert directive for typed_v128 testPut back `#[wasmtime_test(wasm_features(simd),strategies(not(Winch)))]`; the reason why this tests shouldn't runwith Winch is because it requires AVX, but we can have a generic ruleat the test config level since not all SIMD based tests require AVX,it really depends on which SIMD instructions are used.
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 Wasmtim
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
winch(aarch64): Run wast test in CI (#10750)* winch(aarch64): Run wast test in CICloses https://github.com/bytecodealliance/wasmtime/issues/9566This commit takes inspiration fromhttps://github
winch(aarch64): Run wast test in CI (#10750)* winch(aarch64): Run wast test in CICloses https://github.com/bytecodealliance/wasmtime/issues/9566This commit takes inspiration fromhttps://github.com/bytecodealliance/wasmtime/pull/10738/filesDuring the 2025-05-07 Cranelift meeting we discussed potential avenuesto start running wast tests for winch-aarch64. One potential idea wasto declare an allowlist of tests that should be exectued andpotentially ignore everyhing else. Although that idea works, I decidedto diverge a bit from it, in favor of introducing a very strictclassification of the state of tests for aarch64, namely, in thiscommit tests are classified as:* Run and expected to pass* Run and exepected to fail in a recoverable way* Don't run since it's known that they produce an unrecoverable errore.g., segafault.This approach is probably more verbose than the one discussed in themeeting, however, I think it's easier to have a global view of thatstatus for aarch64 and potentially other backends in the future.* Formatting* Extract common tests that fail in all targets* Move the `Compiler::should_fail` call at runtime`Compiler::should_fail` makes use of `#[cfg(target_arg="...")]` directives toderive the compiler-arch-Wasm proposal support matrix, however,`Compiler::should_fail` is also called from the `wasmtime_test` macrowhich introduces conflicts with the `target_arch` resolution (within macros,these directives resolve to the host compiler, instead of the target).This commit emits `Compiler::should_fail` at runtime instead of atcompile time, which fixes the issue mentioned above.* Use `.unwrap` when test is expected to pass
`cranelift-frontend`: Propagate needs-stack-map from variables to values during finalization (#10468)* cranelift-frontend: Propagate needs-stack-map from variables to values during finalizationRa
`cranelift-frontend`: Propagate needs-stack-map from variables to values during finalization (#10468)* cranelift-frontend: Propagate needs-stack-map from variables to values during finalizationRather than trying to propagate the needs-stack-map bit from variables to valuesonline, while we are building the IR and defining and using variables, waituntil the function is being finalized, and then propagate everything all atonce. This avoids potential repeated work and is easier to ensure that it iscomplete and covers all values associated with a variable, since by the time weare finalizing the function, we won't add any new values for a variable that wewill need to keep track of and propagate this information to.This also means that we can remove the `params_added_to_blocks` vector from theSSA side effects structure, since it was only used to online-update the`stack_map_values` set.* Initialize the env-logger in `#[wasmtime_test]`* Fix needs-stack-map set iterationFor reasons I do not understand, the `EntitySet::keys` method includes keys thatare not in the set, and we have unit tests asserting this bizarre behavior. Veryperplexing. So I added a new method to iterate over just the elements of theset.
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. Specific
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
Add Pulley support to wasmtime_test macro (#10057)* wasmtime_test: Rename "Cranelift" strategy to "CraneliftNative"* wasmtime_test: Add CraneliftPulley to default test strategies* wasmtime_test
Add Pulley support to wasmtime_test macro (#10057)* wasmtime_test: Rename "Cranelift" strategy to "CraneliftNative"* wasmtime_test: Add CraneliftPulley to default test strategies* wasmtime_test: Use one specific compilation strategy with `only` specifier.Tests in `tests/all/fuel.rs` and `tests/all/winch_engine_features.rs`were using `#[wasmtime_test(strategies(not(Cranelift)))]` to gate theirWinch specific tests. Now that there is a third compilation strategy,those tests were failing against Pulley.I've replaced those with `#[wasmtime_test(strategies(only(Winch)))]`to be more clear that they are targeted specifically at Winch.* wasmtime_test: Fix flaky `wrap_and_typed_i31ref` test in tests/all/func.rsThe `static HITS` variable was sharing state between tests,causing them to clobber each other when ran together.
Replace `signals-based-traps` with auto-detection (#9941)* Replace `signals-based-traps` with auto-detectionThis commit refactors the platform support of the `wasmtime` crateitself to remove the
Replace `signals-based-traps` with auto-detection (#9941)* Replace `signals-based-traps` with auto-detectionThis commit refactors the platform support of the `wasmtime` crateitself to remove the previously added `signals-based-traps` feature infavor of auto-detecting whether it's there or not. The `build.rs`script for the `wasmtime` crate will now detect the target platform andauto-enable this feature as necessary.The `signals-based-traps` cargo feature is removed and split into twocustom `#[cfg]` directives that the build script sets:* `has_virtual_memory` - this is used to gate mmap implementations for example. This is enabled on `unix || windows` and will be off for `no_std` targets for example. This is split out of "signals-based-traps" to better handle platforms like iOS which have virtual memory but don't execute native code (removing the need for native signals).* `has_native_signals` - gates signal handlers on Unix for example. This is disabled on MIRI but otherwise enabled for `unix || windows`. This is intended to in the future get disabled for iOS by default for example since it's not necessary when using Pulley. This is additionally off-by-default for `no_std` platforms.Two new crate features were added for `no_std` or "custom" platforms toopt-in to the `wasmtime-platform.h` C APIs for implementing virtualmemory and signals. These are used in the `min-platform` embedding example.This commit additionally updates some various documentation here andthere to be more up-to-date.* Update CI configuration* Fix compile warnings* Fix test on miri* Fix more tests on miri* Fix some warnings* Another round of miri/CI attempts/fixesprtest:full
Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gi
Support executing Pulley in Wasmtime (#9744)* Support executing Pulley in WasmtimeThis commit is the initial implementation of executing the Pulleyinterpreter from the `wasmtime` crate. This gives access to all of the`wasmtime` crate's runtime APIs backed by execution of bytecode inPulley. This builds on the previous PRs I've been making for support inPulley to culminate in testing on CI in this PR. This PR handles somefinal tidbits related to producing a runnable image that can beinterpreted by the `wasmtime` crate such as:* Pulley compilation artifacts are no longer marked as natively executable, just read-only.* Pulley compilation artifacts include wasm-to-array trampolines like normal platforms (removes a pulley special-case).* Dispatch of host calls from Pulley to the Wasmtime runtime are implemented.* Pulley's list of panicking wasm features is slimmed down as most are covered by "this lowering isn't supported" errors.* Execution of wasm code now has an `if` to see whether Pulley is enabled within a `Store` or not.* Traps and basic "unwinding" of the pulley stack are implemented (e.g. a "pulley version" of `setjmp` and `longjmp`, sort of)* Halting the interpreter has been refactored to help shrink the size of `ControlFlow<Done>` and handle metadata with each done state.Some minor refactorings are also included here and there along with afew fixes here and there necessary to get tests passing.The next major part of this commit is updates to our `wast` test suiteand executing all `*.wast` files. Pulley is now executed by default forall files as a new execution engine. This means that all platforms in CIwill start executing Pulley tests. At this time almost all tests areflagged as "expected to fail" but there are a small handful ofallow-listed tests which are expected to pass. This exact list willchange over time as CLIF lowerings are implemented and the interpreteris extended.Follow-up PRs will extend the testing strategy further such as:* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.* Getting testing set up on CI for 32-bit platforms.prtest:full* Fix pulley fuzz build* Fix clippy lints* Shuffle around some `#[cfg]`'d code* Remove unused imports* Update feature sets testing MIRIEnable pulley for wasmtime/wasmtime-cli and also enable all features forwasmtime-environ* Round up pulley's page size to 64k* Skip pulley tests on s390x for now* Add a safety rail for matching a pulley target to the host* Fix more pulley tests on s390x* Review comments* Fix fuzz build
Refactor the `#[wasmtime_test]` macro (#9627)* Refactor the `#[wasmtime_test]` macro* Start tests with a blank slate of features instead of with the default set of features enables (ensures eac
Refactor the `#[wasmtime_test]` macro (#9627)* Refactor the `#[wasmtime_test]` macro* Start tests with a blank slate of features instead of with the default set of features enables (ensures each test explicitly specifies required features)* Reuse test features from `wasmtime_wast_util` to avoid duplicating listings of features. Also shares logic for "should this compiler fail this test because of unsupported features".* Move logic in `tests/wast.rs` to apply test configuration to a `Config` to a new location that can be shared across suites.* Add a new feature for `simd` and flag tests that need it with the feature.This is done in preparation for adding a new compiler strategy of Pulleyto be able to flag tests as passing for pulley or not.* Review feedback
test-macros: Handle custom test attributes (#9602)This commit introduces the ability to pass a custom attribute to theprocedural macro via `#[wasmtime_test(with = "...")]`. This makes itpossible
test-macros: Handle custom test attributes (#9602)This commit introduces the ability to pass a custom attribute to theprocedural macro via `#[wasmtime_test(with = "...")]`. This makes itpossible to use the macro in situations where the caller desires to usea different test attribute such as `#[tokio::test]`.Additionally this commit also introduces support for the test funcitionasyncness, which was previously ignored.This change is mainly motivated by adding epoch interruption support toWinch.
test-macros: Handle dead code warnings (#9492)This commit handles dead code warnings produced by the compiler when themacro is invoked as: #[wasmtime_test(strategies(not(Cranelift))]Which o
test-macros: Handle dead code warnings (#9492)This commit handles dead code warnings produced by the compiler when themacro is invoked as: #[wasmtime_test(strategies(not(Cranelift))]Which occur because Winch currently only offers support for x86_64.The motivation behind this change comes fromhttps://github.com/bytecodealliance/wasmtime/pull/9490, which is wherethe warnings surfaced.
test-macros: Fix default return type (#9469)This commit fixes the handling of default return types in`wasmtime-test-macros`. Prior to this commit, functions returning `()`inserted a `()` after th
test-macros: Fix default return type (#9469)This commit fixes the handling of default return types in`wasmtime-test-macros`. Prior to this commit, functions returning `()`inserted a `()` after the return output, which resulted in a syntaxerror.This commit fixes this issue by quoting empty tokens when the returntype is the default one.
Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting
Fix a typo in the `wasmtime_test` macro (#8801)Follow-up to: https://github.com/bytecodealliance/wasmtime/pull/8789;fixes the validation error message.
Initial migration to `wasmtime_test` (#8789)* Initial migration to `wasmtime_test`This commit introduces the initial migration to the `wasmtime_test`macro.This change starts by migrating all t
Initial migration to `wasmtime_test` (#8789)* Initial migration to `wasmtime_test`This commit introduces the initial migration to the `wasmtime_test`macro.This change starts by migrating all the applicable `func.rs` integrationtests and at the same time it removes all the duplicated integrationtests in `winch.rs`.Additionally, this change introduces a slight change to how the macroworks. Inspired by https://github.com/bytecodealliance/wasmtime/pull/8622#pullrequestreview-2083046911it defaults to including all the known configuration combinations andallows the macro user to opt-out where applicable. This makes the usageof the macro less verbose.The intention is to follow-up with subsequent PRs to migrate the all theapplicable tests.* Remove unused `bail` import* Add the ability to specify `wasm_features`This commit adds the ability to specify `wasm_features` when invokingthe macro.If the feature is off by default, the macro will ensure that the featureis enabled in the resulting config.If the feature is not supported by any of the compiler strategies, notests will be generated for such strategy.
wasmtime: Introduce the `test-macros` crate (#8622)* wasmtime: Introduce the `test-macros` crateThis commit introduces the `test-macros` crate. The whole idea behind this crate is to export a sin
wasmtime: Introduce the `test-macros` crate (#8622)* wasmtime: Introduce the `test-macros` crateThis commit introduces the `test-macros` crate. The whole idea behind this crate is to export a single or multiple macros to make it easier to configure Wasmtime for integration tests. The main use-case at this time, is running a subset of the integration tests with Cranelift and Winch. This crate could be extended to serve other use-cases, like testing pooling allocator and/or GC configurations. This commit introduces a single example of how this macro could be used. If there's agreement on merging this change in some shape or form, I'll follow up with migrating the current tests to use `#[wasmtime_test]` where applicable. Part of what's implemented in this PR was discussed in Cranelift's meeting on [April 24th, 2024](https://github.com/bytecodealliance/meetings/blob/main/cranelift/2024/cranelift-04-24.md), however there are several discussion points that are still "in the air", like for example, what's the best way to avoid the combinatorial explosion problem for the potential test matrix.* Add crate license* Clippy fixes* Remove test-macros from members* Clean up test-macros Cargo.toml- Fix version- Add `[lints]`- Add publish key* Add `TestConfig` and simpify parsingThis commit adds a `TestConfig` struct that holds the supported Wasmtimetest configuration. Additonally this commit introduces a partialfunction parser, in which only the attributes, visibility, and signatureare fully parsed, leaving the function body as an opaque `TokenStream`