These tests were temporarily disabled until required `wasi-libc` fixes made
their way into a Rust release. Now that that has happened, we can enable them.
Note that `send_to_recv_closed_returns_err` remains disabled for a bit longer.
The applicable `wasi-libc` bug was masking a separate bug in Wasmtime, fixed
[here](https://github.com/bytecodealliance/wasmtime/pull/13933). Once that fix
makes its way into a release (presumably v48.0.0), we'll finally be able enable
that test, and that should be the last of the
temporarily-disabled-on-WASI-due-to-bugs tests.
Per https://github.com/bytecodealliance/wasmtime/pull/13558, Wasmtime v46.0.1
was the last release to support `wasm32-wasip1-threads`, so we use that for the
WASIp1 testing.
For WASIp2, we should be able to use any recent version of Wasmtime, but we pin
to a specific version anyway to avoid surprises.
Motivation
This adds networking support for the `wasm32-wasip2` target platform, which
includes more extensive support for sockets than `wasm32-wasip1`.
Solution
The bulk of the changes are in https://github.com/tokio-rs/mio/pull/1931. This
patch mainly tweaks a few `cfg` directives to indicate `wasm32-wasip2`'s
additional capabilities.
Note that this is a draft PR until until
https://github.com/tokio-rs/mio/pull/1931 and
https://github.com/rust-lang/socket2/pull/639 have been include in stable
releases of their respective projects.
Also note that I've added a `wasm32-wasip2` target to CI and triaged each test
which was previously disabled for WASI into one of three categories:
- Disabled on both WASIp1 and p2 due to not-yet-supported features such as multithreading
- Disabled on p1 but enabled on p2
- Disabled on p1 and _temporarily_ disabled on p2 due to `wasi-libc` bugfixes which have been merged but not yet included in a Rust release. I'll open an issue to re-enable them when the fixes land in Rust.
Future Work
In the future, we could consider adding support for `tokio::net::lookup_host`.
WASIp2 natively supports asynchronous DNS lookups and is single threaded,
whereas Tokio currently assumes DNS lookups are blocking and require
multithreading to emulate async lookups. A WASIp2-specific implementation could
do the lookup directly without multithreading.
WASIp2 also supports single-threaded, asynchronous file I/O, timers, etc. We
could either support those directly or wait for WASIp3's multithreading support,
in which case most of `tokio::fs` (as well as `tokio::net::lookup_host`, etc.)
_should_ work unchanged via `wasi-libc` and worker threads.
Currently, building for WASIp2 requires RUSTFLAGS="--cfg tokio_unstable"`. Once
we have a solid maintenance plan, we can remove that requirement.
