commit 018d26972e523b8d28f9579056185a1713949dfd
author bors <bors@rust-lang.org> Tue Dec 09 05:10:32 2025 +0000
committer bors <bors@rust-lang.org> Tue Dec 09 05:10:32 2025 +0000
tree 10bd4e8f30c0d0e82f5ecce8c3f1c109e325e6e9
parent a371038013f4f3e3f1d4fdcacfaa02c3252a518b
parent ba462864f1175690d1925cb5b1c6bf0a0c3cb579

Auto merge of #147572 - alexcrichton:wasi-use-libc, r=Mark-Simulacrum

std: Use more `unix.rs` code on WASI targets

This commit is a large change to the implementation of filesystem and
other system-related operations on WASI targets. Previously the standard
library explicitly used the `wasi` crate at the 0.11.x version track
which means that it used WASIp1 APIs directly. This meant that `std` was
hard-coded to use WASIp1 syscalls and there was no separate
implementation for the WASIp{2,3} targets, for example. The high-level
goal of this commit is to decouple this interaction and avoid the use of
the `wasi` crate on the WASIp2 target.

Historically when WASIp1 was originally added to Rust the wasi-libc
library was in a much different position than it is today. Nowadays Rust
already depends on wasi-libc on WASI targets for things like memory
allocation and environment variable management. As a libc library it
also has all the functions necessary to implement all filesystem
operations Rust wants. Recently wasi-libc additionally was updated to
use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using
`wasm32-wasip1` APIs. This commit is leveraging this work by enabling
Rust to completely sever the dependence on WASIp1 APIs when compiling
for `wasm32-wasip2`. This is also intended to make it easier to migrate
to `wasm32-wasip3` internally in the future where now only libc need be
updated and Rust doesn't need to explicitly change as well.

The overall premise of this commit is that there's no need for
WASI-specific implementation modules throughout the standard library.
Instead the libc-style bindings already implemented for Unix-like
targets are sufficient. This means that Rust will now be using
libc-style interfaces to interact with the filesystem, for example, and
wasi-libc is the one responsible for translating these POSIX-ish
functions into WASIp{1,2} calls.

Concrete changes here are:

* `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x`
* The implementation of `std::os::wasi::fs`, which was previously
  unstable and still is, now has portions gated to only work on the
  WASIp1 target which use the `wasi` crate directly. Traits have been
  trimmed down in some cases, updated in others, or now present a
  different API on WASIp1 and WASIp2. It's expected this'll get further
  cleanup in the future.
* The `std::sys::fd::wasi` module is deleted and `unix` is used instead.
* The `std::sys::fs::wasi` module is deleted and `unix` is used instead.
* The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used
  instead.
* The `std::sys::pal::{wasip1,wasip2}` modules are now merged together
  as their difference is much smaller than before.
* The `std::sys::pal::wasi::time` is deleted and the `unix` variant is
  used directly instead.
* The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix`
  variant is used instead.
* The `std::sys::thread::wasip{1,2}` modules are deleted and the `unix`
  variant is used instead.

Overall Rust's libstd is effectively more tightly bound to libc when
compiled to WASI targets. This is intended to mirror how it's expected
all other languages will also bind to WASI. This additionally has the
nice goal of drastically reducing the WASI-specific maintenance burden
in libstd (in theory) and the only real changes required here are extra
definitions being added to `libc` (done in separate PRs). This might be
required for more symbols in the future but for now everything should be
mostly complete.