Stream: rust-toolchain

Topic: Wasmtime as `cargo test` runner: panicking tests

Joel Dice (Oct 29 2026 at 17:51):

Per https://github.com/tokio-rs/mio/issues/2019#issuecomment-5999085006, we noticed that, when using wasmtime run as the test runner, e.g. CARGO_TARGET_WASM32_WASIP2_RUNNER='wasmtime run' cargo test --target wasm32-wasip2, a panicking test causes a trap, leading wasmtime run to exit with a non-zero exit code, causing cargo test to error out. That's all as one would expect given that none of Rust's wasm32-* targets unwind on panic, so the test harness never gets a chance to fail the test gracefully. Presumably, the only way to make that work would be to add support for panicking via Wasm exception handling at some point to one or more Rust Wasm targets.

Also, as a side effect of the above, you don't get to actually see the panic message that was printed to stderr unless you pass --no-capture, which is non-obvious and makes e.g. CI failure diagnostics painful.

Two questions:

• Is there a plan to do that, i.e. add panic unwinding, catch_unwind, etc. via Wasm exception handling?
• If not (or if so, but in the meantime), what's the best practice for running tests for Wasm targets? Just always pass --no-capture? Maybe run each test in its own process? Use cargo-nextest, which seems to do the right thing for this scenario out-of-the-box?

Joel Dice (Oct 29 2026 at 18:18):

For the record, my solution for mio is to use cargo-nextest

Alex Crichton (Oct 29 2026 at 18:58):

Using this documentation to enable unwinding cargo test should work as-is no other changes needed (failing tests print like on native)

Otherwise though the easiest interim fix is cargo nextest IMO. As for changing things by default on the target, I don't think we can do that just for testing, it'll be a target-wide change which makes it a broader topic

Joel Dice (Oct 29 2026 at 18:58):

Yeah, I wouldn't expect it to be only for testing

Last updated: Oct 31 2026 at 23:03 UTC