First wasip3 test #120

wingo · 2025-08-25T14:28:56Z

Depends on #114. Adds wasm32-wasip3 Rust test directory, with a first Rust-based test. Test runner not yet updated; requires passing Wcomponent-model-async=y -Sp3=y to wasmtime. Building the wasip3 tests requires a nightly Rust toolchain, so let's use that too for wasip1.

wingo · 2025-08-26T08:46:49Z

Updated to assert that no duration is greater than a day, under the assumption that the test takes less than a day to run, in terms of the monotonic clock.

rvolosatovs · 2025-08-26T12:26:56Z

tests/rust/wasm32-wasip3/src/bin/monotonic-clock.rs

+    async fn run() -> Result<(), ()> {
+        test_wait_for().await;
+        test_wait_until().await;
+        test_resolution();


I think this is missing the test for these cases:

wait_for with a negative duration

wait_for with a 0 duration

wait_until now

The expectation is that these are ready immediately and the future does not return Poll::Pending, see https://github.com/bytecodealliance/wasmtime/blob/e767c56b824e5ce8947997b052859e050419d35b/crates/test-programs/src/bin/p3_clocks_sleep.rs#L26-L49

Hmm, I am not so sure:

There is no such thing as a negative duration in the spec.

wait_for with 0 duration is not specified to immediately return.

wait_until(now()) may block indefinitely if now() wraps around.

Started a discussion here this morning, fwiw: https://bytecodealliance.zulipchat.com/#narrow/channel/219900-wasi/topic/wasi.3Aclocks.2Fmonotonic-clock.20language

Looks like we need to update the spec

These have been the expectations we had in p2 as well https://github.com/bytecodealliance/wasmtime/blob/e767c56b824e5ce8947997b052859e050419d35b/crates/test-programs/src/bin/preview2_sleep.rs

There is no such thing as a negative duration in the spec.

Rather than wait_for negative duration I should have said wait_until with an instant in the past

wait_until(now()) may block indefinitely if now() wraps around.

I'm not sure I agree.

Assume time T_start

now() is called, returns T_1. T_1 < T_start, because the clock has wrapped around since T_start

wait_for is called with T_1

wait_for returns immediately, since time is now T_2 and T_2 > T_1

I guess this is again a question of waiting for an instant in the past.

I strongly disagree, in fact, that waiting for an instant in the past should block indefinitely, since due to non-determinism it seems awfully easy to end up in a deadlock this way

Oh sure, I think I am on board with the design, but I think the spec doesn't reflect the design currently: there is actually no way to know that an instant is in the past, given wraparound. We could specify that the range of return values of now() is less than 2^63 during the execution of a component, that would allow us to identify an instant "in the past". Some spec work needed here!

There are some slightly stale spec changes proposed in WebAssembly/wasi-clocks#71

wingo · 2025-08-27T11:19:03Z

Rebased on Per-target rust testsuite #114 to resolve conflicts.
No longer assumes that monotonic_clock::now() wraps; tests the opposite.
Add some wait_for(0), wait_until(0), etc tests.

wingo · 2025-08-27T11:54:24Z

Rebased to remove dependent branches from the diff

.github/workflows/compile-tests.yml

loganek · 2025-08-27T22:19:56Z

tests/rust/build.py

@@ -21,7 +21,7 @@
    args.verbose = True

 SYSTEMS = ['wasm32']
-VERSIONS = ['wasip1'] # + ['wasip2', 'wasip3']


did you mean wasip2? I see in the compile-tests.yml workflow you configure wasip2 target, not wasip3

It's right as-is: the wasip3 interfaces and toolchain are still under development. There will be no wasm32-wasip3 toolchain until the release is blessed. Until then, one compiles with the wasm32-wasip2 toolchain. But they are indeed wasip3 tests.

I think this is quite confusing and perhaps requires a bit of re-thinking how we define test cases overall.
Perhaps in the test suite metadata we should specify the minimum / maximum version of the WASI version that the test is compatible with, and then the test runner can select an appropriate set of tests to run based on parameters?

Agreed with regards to having a shortcut to run e.g. "just the wasip1 tests". But from a directory structure / test suite definition perspective, I don't know how to be more clear: the test sources are in tests/rust/wasm32-wasip3, and the binaries get written to tests/rust/testsuite/wasm32-wasip3. They test wasip3 APIs. That they are compiled with a toolchain named "wasip2" is a temporary detail that will go away once the wasip3 release is out.

@wingo I agree that its clear when you lay it out that way - can you add text to the readme that describes how the tests for wasi are in tests//wasi, and a comment here in this build script that says wasip2 is an implementation detail until wasip3 ships in rustc?

I'm curious what's your long-term plan for adding more tests? Let's say we'll have wasip4 at some point of time, would they go to the wasip4 folder? But then what about tests in wasip3 - are they expected to be copied to wasip4, or is there assumption that all wasip(N-1) work with wasip(N)?

No, there's no assumption that tests from wasip(N-1) work in wasip(N) - wasi revisions are where we are allowed to make breaking changes, whether because the prior interfaces were flawed or because new component model features allow us to change. So, when its time to add wasip4 (or wasi 1.0 or etc) we'd probably start by making a copy of the prior tests and then making whatever necessary changes according to what changed in the spec.

loganek · 2025-08-27T22:29:44Z

tests/rust/wasm32-wasip3/wit/deps/wasi-cli-0.3.0-rc-2025-08-15/package.wit

@@ -0,0 +1,202 @@
+package wasi:[email protected];


I'm not a wit expert, but can we, instead of copying the files, pull them as a submodule from the original repo: https://github.com/WebAssembly/wasi-cli/ ?

We actually pull them automatically using wkg; I would like to switch to do this as part of the build, but as a followup.

rvolosatovs · 2025-08-28T07:40:24Z

tests/rust/wasm32-wasip3/src/bin/monotonic-clock.rs

+    let end = monotonic_clock::now();
+    assert!(compute_duration(start, end) >= 1 * MILLISECOND);
+
+    monotonic_clock::wait_for(0).await;


I would expect this to assert that the future is immediately Poll::Ready like we do in the Wasmtime tests

Hmm, where is that specified?

WebAssembly/wasi-clocks#97

wingo · 2025-08-28T15:18:12Z

Okeysmokes, I have done all I want to do here, can follow up with the tests suggested by @rvolosatovs if the spec merges, happy to address other concerns from @loganek, otherwise let me know what's up. Thanks :)

pchickey approved these changes Aug 25, 2025

View reviewed changes

wingo force-pushed the first-wasip3-test branch from 74482cb to 40c7c9d Compare August 26, 2025 08:45

rvolosatovs reviewed Aug 26, 2025

View reviewed changes

wingo force-pushed the first-wasip3-test branch from 40c7c9d to 59c3aa7 Compare August 27, 2025 11:17

wasip3: Add first test for wasi:clocks/monotonic-clock

15cdb3c

wingo force-pushed the first-wasip3-test branch from 59c3aa7 to 15cdb3c Compare August 27, 2025 11:54

loganek reviewed Aug 27, 2025

View reviewed changes

.github/workflows/compile-tests.yml Show resolved Hide resolved

loganek reviewed Aug 27, 2025

View reviewed changes

rvolosatovs reviewed Aug 28, 2025

View reviewed changes

Use stable toolchain for wasip1 Rust builds

3face54

wingo mentioned this pull request Aug 28, 2025

Add tests for wasip3 wall_clock and for multiple outstanding wait_for invocations #123

Open

Allow different wasi versions to use different Rust channels

902d562

wingo force-pushed the first-wasip3-test branch from 98e5084 to 09f8234 Compare August 28, 2025 15:10

Attempt to fix git workflow

001c798

wingo force-pushed the first-wasip3-test branch from 09f8234 to 001c798 Compare August 28, 2025 15:12

rvolosatovs approved these changes Aug 28, 2025

View reviewed changes

alexcrichton mentioned this pull request Aug 28, 2025

Flag wasi:cli/run#run as an async function WebAssembly/wasi-cli#79

Open

First wasip3 test #120

Are you sure you want to change the base?

First wasip3 test #120

Conversation

wingo commented Aug 25, 2025

Uh oh!

wingo commented Aug 26, 2025

Uh oh!

rvolosatovs Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wingo Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wingo commented Aug 27, 2025

Uh oh!

wingo commented Aug 27, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wingo commented Aug 28, 2025

Uh oh!

Uh oh!

rvolosatovs Aug 26, 2025 •

edited

Loading

wingo Aug 26, 2025 •

edited

Loading