std: Use more unix.rs code on WASI targets

[alexcrichton]

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.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Mark-Simulacrum]

At a high level this seems OK (cc @joboet as you've been working on a bunch of sys cleanups).

If I'm understanding the new code right, it looks like the future we'd expect is to remove the wasi modules entirely in favor of wasipN being cfg(unix) for the most part? Does that understanding seem right? I see that a bunch of the code "added" here seems like it's copy/paste from cfg(unix) modules counterparts.

For example, maybe library/std/src/sys/io/io_slice/wasi.rs should already be removed and cfgs rerouted to the iovec module, with the extra methods gated on cfgs in that? I think that would also apply to other similar modules at this point. Diffing locally (diff -u <(git show cb4a430b8349d9216f2c58d921a1b3a5aa6a6652:library/std/src/sys/io/io_slice/wasi.rs) library/std/src/sys/io/io_slice/iovec.rs | less) it seems like the only real difference is the extra conversion methods.

[alexcrichton]

That's a good point! You have also made me realize that most of the fs implementation is entirely redundant as well. Almost all of the functions the unix variant uses are implemented by wasi-libc which means we could use wasi-libc directly. The original reason for wasi having its own implementation was to implement everything natively in Rust which requires handling preopens to translate "open this path" to "open this sub-path rooted from this fd", or changing open calls to openat effectively. That's all done internally by wasi-libc anyway, however, so there's not really any need for rust's standard library to duplicate all of that any more.

The main difference between wasi and unix comes down to extensions where on Unix there's all sorts of extra symbols/extensions/etc. That could be handled relatively easily internally though with #[cfg] in the unix implementation (which already has a lot of #[cfg]). Basically I'm rationalizing to myself that I believe it still makes sense for wasi to not be cfg(unix), but using the unix implementations locally within the standard library could make sense.

Lemme test out those ideas and see if I can't delete even more code here.

[alexcrichton]

Ok I think that actually worked out really well -- alexcrichton@6760496 -- so I'm going to switch this PR to taking that approach. Effectively WASIp{1,2,3} will look like "unix" for operations related to the filesystem, threads, timers, etc. There's still platform differences for things like getting arguments and other bits here and there but I think those, in the limit of time, can go through libc as well.

Effectively wasi-libc has matured/changed enough to the point that I think it's more reasonable to go through that for various calls and that should reduce the size of the WASI-specific burden in the standard library. Additionally this reduces the distinction between WASIp1 and WASIp2 even further to by unifying their "pal" module into one since there's virtually no difference now. Overall this feels like a much better state of affairs to me.

This all depends on various libc changes, however, so I'll work on getting those upstream. In the meantime I'll mark this as a draft and I'll ping when this is ready for another round once libc is updated.

[bors]

☔ The latest upstream changes (presumably #147838) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

I've updated this and code-wise it's where I'm pretty comfortable. This is still blocked on a libc release to get merged so I'm leaving this in draft form, but if anyone's curious to take a look and read the updated description/etc it should all be there now.

[alexcrichton]

Looks like I forgot to actually push last time... I've rebased and additionally deleted the wasip2-specific network-related module so now it also shares unix.rs for networking things. Still blocked on a libc release though

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

fmt check
fmt: checked 6537 files
tidy check

thread 'deps (.)' (3868) panicked at src/tools/tidy/src/deps.rs:643:24:
cmd.exec() failed with `cargo metadata` exited with an error: error: failed to load source for dependency `libc`

Caused by:
  Unable to update /libc

Caused by:
---
   5: std::thread::scoped::scope::<rust_tidy::main::{closure#4}, ()>
   6: rust_tidy::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 /node/bin/npm --extra-checks=py,cpp,js,spellcheck` failed with exit code 101
Created at: src/bootstrap/src/core/build_steps/tool.rs:1549:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1279:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:00:53
  local time: Fri Nov 14 22:15:28 UTC 2025
  network time: Fri, 14 Nov 2025 22:15:28 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"