8a42768f - Update nightly used in CI (#10957)

Fri, 06 Jun 2025 18:06:28 +0000

Update nightly used in CI (#10957)A new lint was added to rustc so this updates the nightly used in CI andthen additionally fixes the lints that are firing. List of files: /wasmtime-44.0.1/crates/test-programs/artifacts/src/lib.rs

b98f75aa - Bump MSRV to 1.84.0 (#10520)

Thu, 03 Apr 2025 17:02:19 +0000

Bump MSRV to 1.84.0 (#10520)* Bump MSRV to 1.84.0Coupled with today's release of 1.86.0* Fix tests on windows List of files: /wasmtime-44.0.1/crates/test-programs/artifacts/src/lib.rs

4a096c8e - Use an incremental cache when testing WASI (#8354)

Fri, 12 Apr 2024 23:11:47 +0000

Use an incremental cache when testing WASI (#8354)Currently we've got a good number of WASI tests and they're allrelatively large. We also can run a single test in up to threeconfigurations:* As-is with a module* As a component in "sync" mode* As a component in "async" modeIn debug mode compilation of all these modules can take a significantchunk of time (20-30s in total for test suites) This commit updatesthese test suites to use an in-memory per-process incremental cachebacked by a simple `Mutex`. This gives some good speedups indebug mode, locally the wasi-common, wasmtime-wasi, andwasmtime-wasi-http test suites were reduced from 32 to 17 seconds. I'dexpect larger speedups on less-parallel machines such as our CI. List of files: /wasmtime-44.0.1/crates/test-programs/artifacts/src/lib.rs

b110e57e - preview 1 test-programs: fdflags_sync always unsupported (#7806)

Wed, 24 Jan 2024 00:03:22 +0000

preview 1 test-programs: fdflags_sync always unsupported (#7806)* preview 1 test-programs: fdflags_sync always unsupportedwe never pursued making the fdflags_sync supported on any platform. rather than carry around this baggage, delete the configuration variable and make the single test that considered it always assert that fdflags_sync is not supported.* fix warning List of files: /wasmtime-44.0.1/crates/test-programs/artifacts/src/lib.rs

f4be3606 - Refactor the test-programs test suite (#7182)

Mon, 09 Oct 2023 19:22:42 +0000

Refactor the test-programs test suite (#7182)* Refactor the test-programs test suiteThis commit is a large refactoring that reorganizes `test-programs` andhow we tests wasms in Wasmtime. Often writing tests requires complicatedinteractions with the guest which can't be done via hand-written `*.wat`syntax and requires a compiler to get engaged. For this purpose Wasmtimecurrently has the `crates/test-programs/*` test suite which builds filesfrom source and then runs the tests. This has been somewhat cumbersomein the past though and it's not been easy to extend this over time, sothis commit attempts to address this.The scheme implemented in this PR looks like:* All wasm test programs live in `crates/test-programs/src/bin/*.rs`. All of them, no exceptions.* Wasm tests have shared support located at `crates/test-programs/src/lib.rs` and its submodules, such as bindings generation for WASI.* Wasm tests are built by a new `crates/test-programs/artifacts` crate. This crate compiles modules and additionally creates components for all test programs. The crate itself only records the path to these outputs and a small amount of testing support, but otherwise doesn't interact with `wasmtime`-the-crate itself.* All tests in `crates/test-programs/tests/*.rs` have moved. For example wasi-http tests now live at `crates/wasi-http/tests/*.rs`. Legacy tests of wasi-common now live at `crates/wasi-common/tests/*.rs`. Modern tests for preview2 live at `crates/wasi/tests/*.rs`.* Wasm tests are bucketed based on their filename prefix. For example `preview1_*` is tested in wasi-common and wasmtime-wasi. The `preview2_*` prefix is only tested with wasmtime-wasi, however.* A new `cli_*` prefix is used to execute tests as part of `tests/all/main.rs`. This is a new submodule in `tests/all/cli_tests.rs` which executes these components on the command line. Many old "command" tests were migrated here.* Helper macros are generated to assert that a test suite is run in its entirety. This way if a `preview1_*` test is added it's asserted to get added to both wasi-common and wasmtime-wasi in the various modes they run tests.Overall this moved a number of tests around and refactored some edges ofthe tests, but this should not lose any tests (except one that wasn'tactually testing anything). Additionally the hope is that it's mucheasier to add tests in the future. The process is to add a new file in`crates/test-programs/src/bin/*.rs` named appropriately. For example apreview2 executable is `preview2_*` and a CLI tests is `cli_*`. Whenbuilding the test suite an error is generated in the appropriate modulethen of "please write a test here", and then a test is written in thesame manner as the other tests in the module.* Remove no-longer-needed fetchesprtest:full* I'm worried wasi is running low on semicolons* Add the WASI target in all CI actions* Add unknown-unknown target on all CI builders too* Fix building test artifacts under miriNeed to avoid wrappers for these cross-compiled targets* Break circular dependency for packagingDon't use the workspace dep for `wasmtime-wasi` since it injects aversion, instead use a `path = '..'` dependency to fool Cargo intodropping the dependency during the package phase.* Fix some merge conflicts with tests* Fix rebase for new tests* Remove stray comment* Fix some flaky tests* Fix network tests in synchronous modeThis commit is an attempt to fix some networking tests in synchronousmode in our test suite. Currently networking tests don't actually run insynchronous mode on CI which is why no failures have been surfaced yet,but the refactoring in #7182 is going to start doing this.Currently the `udp_sample_application.rs` test blocks infinitely insynchronous mode for me locally, most of the time. This appears to be aninteraction between how Tokio handles readiness and how we'reentering the event loop. We're effectively entering the Tokio event loopwith a future that's always ready which ends up starving Tokio ofotherwise performing its background work such as updating flags forreadiness of reading/writing.The fix here is to add a yield at the start of an `in_tokio` block whichis used in synchronous mode. This is a kludge fix but the intention isto enable Tokio to have a chance to update readiness flags and processevents from epoll/kqueue/etc.An additional fix to this issue is WebAssembly/wasi-sockets#64 where thetest is waiting on `READABLE` or `WRITABLE`, but in this specific caseit should only wait on `READABLE`. If it waited on just this then thatwould also fix this issue. Nevertheless having a `yield_now` is expectedto have little-to-no overhead and otherwise fix this edge case of analways-ready future.* Fix passing empty arguments on the CLI* Add another blocking accept* Update crates/test-programs/src/bin/api_proxy.rsCo-authored-by: Trevor Elliott ---------Co-authored-by: Trevor Elliott List of files: /wasmtime-44.0.1/crates/test-programs/artifacts/src/lib.rs

Changes in lib.rs

8a42768f - Update nightly used in CI (#10957)

b98f75aa - Bump MSRV to 1.84.0 (#10520)

4a096c8e - Use an incremental cache when testing WASI (#8354)

b110e57e - preview 1 test-programs: fdflags_sync always unsupported (#7806)

f4be3606 - Refactor the test-programs test suite (#7182)