tests: check wasm wasi p1 p2 p3 process exit code

[eduardomourar]

This adds a run-make test for the wasm wasi preview1, preview2
and preview3 exit code.

The test checks that the process exit code for wasm32-wasip1,
wasm32-wasip2 and wasm32-wasip3 are preserved as an integer
instead of original (wasip2 < 0.2.12) returning 0 (success) or 1 (fail).

r? alexcrichton

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @alexcrichton (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[alexcrichton]

Could you expand a bit on the rationale for this? In the abstract there's quite a lot of functionality that isn't tested on WASI targets, but I don't think it's necessarily worth adding tests for everything. In a sense much of the robustness story for the target relies on sharing unix.rs-style code and having tests in wasi-libc for things like this.

[eduardomourar]

I agree that wasi-libc should have coverage for this, but I think there is still value in having a Rust-side test here.

The issue is that Rust is consuming the libc.a from the WASI sysroot, so a change in the WASI SDK/sysroot can change the behavior of std::process::exit() without any Rust code changing.

I couldn’t find an existing wasi-libc test that covers this Rust integration/end-to-end case. Without this test, we could update the WASI SDK again and regress the exit code behavior without catching it in the Rust test suite.

So I see the wasi-libc test and this test as covering different boundaries: wasi-libc tests its implementation, while this verifies that a Rust wasm32-wasip2 (as well as other versions) program actually gets the expected exit code.

[eduardomourar]

Just another point to bringing to you attention. This is catching an actual breaking change: the test fails with WASI SDK 33 and passes with SDK 34. So I think it’s useful to keep as a regression test.

[alexcrichton]

The reason I bring this up is that I'd consider it a pretty hefty and weighty ask to run more CI for wasm than is already done. This is tripling the wasm coverage for what I subjectively view as very little gain. The change in behavior from 33 to 34 wasn't a regression, that was an intentional change inside of wasi-sdk/wasi-libc.

I'd like to move all testing to wasip3 at some point in the future, but I'd like to do so in conjunction with having threads enabled and additionally running tests with panic=unwind to be able to actually run a nontrivial amount of the test suite. That's a pretty separate change, though, and I still don't think it's worth it to have wasm/wasi-specific tests like this. I feel that this is too niche to be testing in rust-lang/rust given the constraints necessary to test wasm/wasi.

[eduardomourar]

I agree with you that it might be too niche to live in this repo, but I do think these particular tests are actually important. So should I move them to https://github.com/WebAssembly/wasi-testsuite/tree/main/tests/rust or to wasmtime repo?

BTW, I meant before that the test is to catch future regression, not that it existed already.

[alexcrichton]

Personally I don't think there's a good spot for a test like this. In essence you want to test 2 things, one is that wasi-libc handles the exit code provided and the second is that Rust uses the exit function in wasi-libc. Rust here has no control over the implementation of wasi-libc, so it's not useful to have a test IMO, and I don't think it's worth having a test that a certain libc symbol is used to implement a function here.