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

alexcrichton · 2025-10-10T21:25:47Z

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 · 2025-10-10T21:25:52Z

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 · 2025-10-11T19:29:55Z

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 · 2025-10-13T15:13:31Z

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 · 2025-10-13T22:05:19Z

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.

This commit fills out definitions in libc for rust-lang/rust#147572 notably filling out some fs-related functions as well as many pthread-related functions. The pthread-related functions were not available originally with wasi-libc but nowadays are stubs for single-threaded behavior. The goal is to make wasi targets more "unix like" in libstd and have less WASI-specific code.

bors · 2025-10-18T10:51:02Z

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

alexcrichton · 2025-11-01T18:11:22Z

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.

This commit fills out definitions in libc for rust-lang/rust#147572 notably filling out some fs-related functions as well as many pthread-related functions. The pthread-related functions were not available originally with wasi-libc but nowadays are stubs for single-threaded behavior. The goal is to make wasi targets more "unix like" in libstd and have less WASI-specific code. (backport <rust-lang#4747>) (cherry picked from commit 702efb9)

This commit fills out definitions in libc for rust-lang/rust#147572 notably filling out some fs-related functions as well as many pthread-related functions. The pthread-related functions were not available originally with wasi-libc but nowadays are stubs for single-threaded behavior. The goal is to make wasi targets more "unix like" in libstd and have less WASI-specific code. (backport <#4747>) (cherry picked from commit 702efb9)

alexcrichton · 2025-11-14T22:12:49Z

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

bors · 2025-11-29T06:23:41Z

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

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 · 2025-12-08T14:46:42Z

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.

alexcrichton · 2025-12-08T14:46:47Z

@bors: r=Mark-Simulacrum

bors · 2025-12-08T14:46:50Z

📌 Commit ba46286 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

…-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.

Rollup of 12 pull requests Successful merges: - #147572 (std: Use more `unix.rs` code on WASI targets) - #148491 ( Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type) - #149215 (Emit `check-cfg` lints during attribute parsing rather than evaluation) - #149652 (Add release notes for 1.92.0) - #149720 (rustdoc book: mention inner doc attribute) - #149730 (lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE) - #149754 (Retire `opt_str2` from compiletest cli parsing) - #149755 (bootstrap: Use a `CompiletestMode` enum instead of bare strings) - #149763 (Add inline attribute to generated delegation function if needed) - #149772 (test: Add a test for 146133) - #149779 (Fix typo "an" → "and") - #149782 (Remove `[no-mentions]` handler in the triagebot config) r? `@ghost` `@rustbot` modify labels: rollup

bors · 2025-12-09T05:10:35Z

⌛ Testing commit ba46286 with merge 018d269...

bors · 2025-12-09T08:19:43Z

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 018d269 to main...

github-actions · 2025-12-09T08:22:25Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing a371038 (parent) -> 018d269 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 018d26972e523b8d28f9579056185a1713949dfd --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

aarch64-apple: 9680.9s -> 6859.4s (-29.1%)
dist-aarch64-apple: 7815.3s -> 6106.3s (-21.9%)
x86_64-gnu-debug: 7273.9s -> 6043.0s (-16.9%)
tidy: 166.0s -> 189.0s (+13.8%)
x86_64-rust-for-linux: 3127.4s -> 2698.0s (-13.7%)
dist-aarch64-msvc: 6121.6s -> 5309.0s (-13.3%)
dist-x86_64-apple: 8053.5s -> 7008.4s (-13.0%)
pr-check-2: 2624.3s -> 2325.6s (-11.4%)
x86_64-gnu-tools: 3577.5s -> 3184.2s (-11.0%)
i686-gnu-2: 6325.4s -> 5648.9s (-10.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2025-12-09T09:04:37Z

Finished benchmarking commit (018d269): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

If the regression was expected or you think it can be justified,
please write a comment with sufficient written justification, and add
@rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
If you think that you know of a way to resolve the regression, try to create
a new PR with a fix for the regression.
If you do not understand the regression or you think that it is just noise,
you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	3
Regressions ❌ (secondary)	0.3%	[0.1%, 0.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.0%	[-0.0%, -0.0%]	1
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	3

Max RSS (memory usage)

Results (primary 2.3%, secondary 1.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.0%, 2.6%]	2
Regressions ❌ (secondary)	1.8%	[1.8%, 1.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.3%	[2.0%, 2.6%]	2

Cycles

Results (primary -2.1%, secondary -5.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.1%	[-2.1%, -2.1%]	1
Improvements ✅ (secondary)	-5.6%	[-5.8%, -5.4%]	2
All ❌✅ (primary)	-2.1%	[-2.1%, -2.1%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 470.343s -> 472.223s (0.40%)
Artifact size: 389.02 MiB -> 389.03 MiB (0.00%)

marxin · 2025-12-10T17:57:18Z

@alexcrichton

Not fully sure about the change, but it seems the recent cargo +nightly started to fail for the following snippet under wasmtime (both latest release and the current tip):

fn main() {
    std::fs::hard_link("/tmp/1.txt", "/tmp/2.txt").unwrap();
}

✦ ❯ cargo +stable b --target=wasm32-wasip1
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
~/Programming/testing-wasmer/hardlink on  main [?] is 📦 v0.1.0 via 🦀 v1.94.0-nightly
✦ ❯ rm /tmp/[12].txt ; touch /tmp/1.txt && wasmtime run --dir /tmp/ ./target/wasm32-wasip1/debug/hardlink.wasm
~/Programming/testing-wasmer/hardlink on  main [?] is 📦 v0.1.0 via 🦀 v1.94.0-nightly
...
✦ ❯ cargo +nightly b --target=wasm32-wasip1
   Compiling hardlink v0.1.0 (/home/marxin/Programming/testing-wasmer/hardlink)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
~/Programming/testing-wasmer/hardlink on  main [?] is 📦 v0.1.0 via 🦀 v1.94.0-nightly
✦ ❯ rm /tmp/[12].txt ; touch /tmp/1.txt && wasmtime run --dir /tmp/ ./target/wasm32-wasip1/debug/hardlink.wasm

thread 'main' (1) panicked at src/main.rs:2:52:
called `Result::unwrap()` on an `Err` value: Os { code: 44, kind: NotFound, message: "No such file or directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `./target/wasm32-wasip1/debug/hardlink.wasm`

Caused by:
    0: failed to invoke command default
    1: error while executing at wasm backtrace:
           0:   0x7aa1 - hardlink-a3f77a71fb778855.wasm!abort
           1:   0x2ebf - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::sys::pal::wasi::helpers::abort_internal
           2:   0x1ffd - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::process::abort
           3:   0x2658 - hardlink-a3f77a71fb778855.wasm!__rustc[47f3c1cf3382b6b6]::__rust_abort
           4:    0xbb0 - hardlink-a3f77a71fb778855.wasm!__rustc[47f3c1cf3382b6b6]::__rust_start_panic
           5:   0x249f - hardlink-a3f77a71fb778855.wasm!__rustc[47f3c1cf3382b6b6]::rust_panic
           6:   0x186c - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::panicking::panic_with_hook
           7:   0x141c - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::panicking::panic_handler::{closure#0}
           8:   0x1380 - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::sys::backtrace::__rust_end_short_backtrace::<std[b3a36c8b3c2dd55]::panicking::panic_handler::{closure#0}, !>
           9:   0x273b - hardlink-a3f77a71fb778855.wasm!__rustc[47f3c1cf3382b6b6]::rust_begin_unwind
          10:   0x907f - hardlink-a3f77a71fb778855.wasm!core[fd3d834f1c490411]::panicking::panic_fmt
          11:   0xbe15 - hardlink-a3f77a71fb778855.wasm!core[fd3d834f1c490411]::result::unwrap_failed
          12:    0x435 - hardlink-a3f77a71fb778855.wasm!hardlink[d927fd67d1fab629]::main
          13:    0x9f0 - hardlink-a3f77a71fb778855.wasm!<fn() as core[fd3d834f1c490411]::ops::function::FnOnce<()>>::call_once
          14:    0x4e5 - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
          15:    0x5eb - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::rt::lang_start::<()>::{closure#0}
          16:   0x2c00 - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::rt::lang_start_internal
          17:    0x5b1 - hardlink-a3f77a71fb778855.wasm!std[b3a36c8b3c2dd55]::rt::lang_start::<()>
          18:    0x462 - hardlink-a3f77a71fb778855.wasm!__main_void
          19:    0x38a - hardlink-a3f77a71fb778855.wasm!_start
       note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information
    2: wasm trap: wasm `unreachable` instruction executed

Plus, the very same problem affects also wasmer, where I noticed the imported path_link function is being called with 2.txt as both the source and link target:
path_link: return=Ok(Errno::noent) old_fd=5 new_fd=5 follow_symlinks=false old_path="tmp/2.txt" new_path="tmp/2.txt" old_path="tmp/2.txt" new_path="tmp/2.txt"

Can you please take a look?

alexcrichton · 2025-12-10T20:37:52Z

Looks like that's a bug in wasi-libc, which I've proposed #149864 as a workaround for now.

marxin · 2025-12-11T04:12:35Z

Thank you for the quick fix of the issue.

rustbot assigned Mark-Simulacrum Oct 10, 2025

This comment has been minimized.

Sign in to view

alexcrichton force-pushed the wasi-use-libc branch from c87de05 to cb4a430 Compare October 10, 2025 22:37

rustbot added A-rustdoc-search Area: Rustdoc's search feature T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. labels Oct 10, 2025

alexcrichton marked this pull request as draft October 13, 2025 22:04

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 13, 2025

alexcrichton mentioned this pull request Oct 14, 2025

Add more wasi definitions for libstd rust-lang/libc#4747

Merged

alexcrichton force-pushed the wasi-use-libc branch from cb4a430 to ffb3ff1 Compare November 14, 2025 22:11

rustbot added the O-unix Operating system: Unix-like label Nov 14, 2025

alexcrichton changed the title ~~std: Use libc for filesystem ops on WASI targets~~ std: Use more unix.rs code on WASI targets Nov 14, 2025

This comment has been minimized.

Sign in to view

alexcrichton force-pushed the wasi-use-libc branch from 805a23c to ba46286 Compare December 8, 2025 14:46

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 8, 2025

Zalathar mentioned this pull request Dec 9, 2025

Rollup of 12 pull requests #149796

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 9, 2025

bors merged commit 018d269 into rust-lang:main Dec 9, 2025
12 checks passed

rustbot added this to the 1.94.0 milestone Dec 9, 2025

bors mentioned this pull request Dec 9, 2025

Make IoSlice and IoSliceMut methods unstably const #144090

Open

rustbot added the perf-regression Performance regression. label Dec 9, 2025

marxin mentioned this pull request Dec 10, 2025

std::fs::hard_link stopped after with rustc +nightly wasmerio/wasmer#5958

Open

alexcrichton deleted the wasi-use-libc branch December 10, 2025 17:59

alexcrichton mentioned this pull request Dec 10, 2025

std: Don't use linkat on the wasm32-wasi* targets #149864

Open

Uh oh!

std: Use more unix.rs code on WASI targets #147572

std: Use more unix.rs code on WASI targets #147572

Conversation

alexcrichton commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Oct 10, 2025

Uh oh!

This comment has been minimized.

Mark-Simulacrum commented Oct 11, 2025

Uh oh!

alexcrichton commented Oct 13, 2025

Uh oh!

alexcrichton commented Oct 13, 2025

Uh oh!

bors commented Oct 18, 2025

Uh oh!

alexcrichton commented Nov 1, 2025

Uh oh!

alexcrichton commented Nov 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

bors commented Nov 29, 2025

Uh oh!

rustbot commented Dec 8, 2025

Uh oh!

alexcrichton commented Dec 8, 2025

Uh oh!

bors commented Dec 8, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

bors commented Dec 9, 2025

Uh oh!

Uh oh!

github-actions bot commented Dec 9, 2025

Test differences

Job duration changes

Uh oh!

rust-timer commented Dec 9, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

marxin commented Dec 10, 2025

Uh oh!

alexcrichton commented Dec 10, 2025

Uh oh!

marxin commented Dec 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

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

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

alexcrichton commented Oct 10, 2025 •

edited

Loading

alexcrichton commented Nov 14, 2025 •

edited

Loading