wasm: support for wasm32-wasip2 target

[eduardomourar]

Add support for the wasm32-wasip2 (WASI Preview 2) target, enabling coreutils to compile and be used on sandboxed environments that can run WebAssembly components.

Changes

• Add wasm32-wasip2 target to CI workflows
• Update code for wasip2 compatibility (yes and uucore libraries)
• Ensure unit tests pass on the new target
• Update documentation about supported platforms

[oech3]

But why? Is there any usecase wasip1 cannot cover? If wasip2 works on web browsers using shim, we should drop wasip1 at the same time.

[eduardomourar]

The main reason to have WASI Preview 2 is because Preview 1 is not being further developed. In wasip1, we would never get full support for streams and socket. With wasip2, on other hand, we will have those as well as support for the WebAssembly Component Model. This documentation might help answering you: https://component-model.bytecodealliance.org/design/why-component-model.html#interoperability

Should we drop wasip1? Probably not yet. There are few features that are missing in Preview2:

• std::os::wasi::prelude::OsStrExt is still under the unstable flag as discussed here
• WASI CLI Exit with code has stabilized but it has not been implemented in rust std
• Generated WASM component cannot be easily loaded yet in the browser. You need JCO to transpile it and include the respective WASI shims in order to have something similar to the Uutils Playground.

[oech3]

Ok. But do you want to publish release binaries too? Or is cargo check or cargo test on the CI enough?

[sylvestre]

why that ?

[eduardomourar]

I have written now in docs/src/wasi-test-gaps.md some details on that. The WASI Preview 2, as currently implemented in Rust std, only allows to exit with code 0 (success) or 1 (failure).

[oech3]

It is limitation for wasip2 instead of ideal behaviour. So we should just guard the test by cfg.

[eduardomourar]

It will be done as part of other PR.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/misc/tty-eof (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/tail/retry (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/cut/cut-huge-range is now being skipped but was previously passing.
Congrats! The gnu test tests/rm/many-dir-entries-vs-OOM is now passing!

[eduardomourar]

Ok. But do you want to publish release binaries too? Or is cargo check or cargo test on the CI enough?

For me, I would benefit of having the released binary for wasip2. I understand it adds a bit more complexity to maintain it, but I think the burden to keep wasip2 is basically the same as wasip1.

[oech3]

Correctness of error handling is unrelated with initial support (cargo build). Please split PR for less diff.

[eduardomourar]

@oech3, done. I only left the changes to run the build successfully. I am skipping the integration tests for wasip2 as it will be part of the PR related to error handling.

[codspeed-hq]

Merging this PR will not alter performance

✅ 64 untouched benchmarks
⏩ 305 skipped benchmarks¹

---

_{Comparing eduardomourar:feat/support-wasm32-wasip2 (02c6ba8) with main (d01be5b)}

Footnotes

1. 305 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[eduardomourar]

@codspeedbot fix this regression

[sylvestre]

this is probably noise, you can ignore the perf warning

[eduardomourar]

@sylvestre and @oech3, I have rebased it. So let me know if you need me to do anything about those perf warnings, ok?

[eduardomourar]

@sylvestre and @oech3, as far I aware there is no other pending issues. If so, this is ready to be approved and merged.

[oech3]

Please fix yes's as_encoded_bytes cfg issue.

[oech3]

(also I have no priv for merge)

[eduardomourar]

Please fix yes's as_encoded_bytes cfg issue.

That was already fixed. I pushed a small change in order to run the integration test of yes command for both wasip1 and wasip2.