You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run p3 integration tests in CI via a harness-free test_main!
The `wstd tests (wasip3)` CI step was broken: p3's `block_on` blocks on
`waitable-set.wait`, which traps ("cannot block a synchronous task before
returning") when driven from libtest's synchronously-lifted `wasi:cli/run`
`main`. p2's `block_on` blocks via `wasi:io/poll.poll`, which a sync task may
do, so only p3 was affected.
Add a dependency-free `wstd::test_main!` macro (plus a `#[doc(hidden)]`
`__test` support module) that provides a `harness = false` entry point for
integration tests:
* on p3 it async-lifts the test binary's `wasi:cli/run` export, so per-test
`block_on` calls are made from an async task and no longer trap;
* on p2 it emits a plain `fn main` that runs each test via `block_on`.
Both variants print libtest-style status lines and exit non-zero when a test
fails (whether it panics or returns `Err`), so `cargo test` still reports
failures. Convert all integration tests to plain `async fn`s driven by
`test_main!` and mark each `[[test]]` target `harness = false`.
To let a single `wasm32-wasip2` build serve both backends, add the
component-model async runner flags (`-Wcomponent-model-async`,
`-Wcomponent-model-more-async-builtins`, `-Wcomponent-model-async-stackful`,
`-Sp3`) to the `wasm32-wasip2` runner. These are inert for plain p2 components,
so the wasip2 suite is unaffected.
Finally, gate the two blocking `src/time.rs` unit tests (`timer_now`,
`timer_after_100_milliseconds`) with `#[cfg_attr(wstd_p3, ignore)]`: they run
under libtest's default (synchronous) harness in the `[lib]` target, which
still traps on p3. Their behavior is covered by the integration test suite.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
0 commit comments