This is similar to prior updates such as 149037 in that this is just
updating a URL. This update though has some technical updates
accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this
target, even for startup. This means that the final binary no longer
has an "adapter" which can help making instantiation of a component a
bit more lean.
* In 147572 libstd was updated to use wasi-libc more often on the
`wasm32-wasip2` target. This uncovered a number of bugs in
wasi-libc such as 149864, 150291, and 151016. These are all fixed in
wasi-sdk-30 so the workarounds in the standard library are all
removed.
Overall this is not expected to have any sort of major impact on users
of WASI targets. Instead it's expected to be a normal routine update to
keep the wheels greased and oiled.
Fix(lib/win/thread): Ensure `Sleep`'s usage passes over the requested duration under Win7
Fixesrust-lang/rust#149935. See the added comment for more details.
This makes the concerned test now reproducibly pass, for us at least. Also, testing this separately revealed successful: see the issue.
@rustbot label C-bug I-flaky-test O-windows-7 T-libs A-time A-thread
fix: WASI threading regression by disabling pthread usage
PR rust-lang/rust#147572 changed WASI to use the Unix threading implementation, but WASI does not support threading. When the Unix code tries to call pthread_create, it fails with EAGAIN, causing libraries like rayon to panic when trying to initialize their global thread pool.
The old wasip1/wasip2 implementations:
- wasip1: Threading conditionally available with atomics (experimental)
- wasip2: Threading unconditionally unsupported
This fix restores that behavior by disabling pthread-based threading for all WASI targets:
1. Guard the pthread-based Thread implementation with #[cfg(not(target_os = "wasi"))]
2. Provide an unsupported stub (Thread(!)) for WASI
3. Return Err(io::Error::UNSUPPORTED_PLATFORM) when Thread::new is called
Fixes the regression where rayon-based code (e.g., lopdf in PDF handling) panicked on WASI after nightly-2025-12-10.
Before fix:
pthread_create returns EAGAIN (error code 6)
ThreadPoolBuildError { kind: IOError(Os { code: 6,
kind: WouldBlock, message: "Resource temporarily unavailable" }) }
After fix:
Thread::new returns Err(io::Error::UNSUPPORTED_PLATFORM)
Libraries can gracefully handle the lack of threading support
r? @alexcrichton
Recent changes made WASI targets use the Unix threading implementation, but
WASI does not support threading. When the Unix code tries to call
pthread_create, it fails with EAGAIN, causing libraries like rayon to
panic when trying to initialize their global thread pool.
This fix adds an early return in Thread::new() that checks for WASI and
returns UNSUPPORTED_PLATFORM. This approach:
- Continues using most of the unix.rs code path (less invasive)
- Only requires a small cfg check at the start of Thread::new()
- Can be easily removed once wasi-sdk is updated with the proper fix
The real fix is being tracked in `WebAssembly/wasi-libc#716` which will
change the error code returned by pthread_create to properly indicate
unsupported operations. Once that propagates to wasi-sdk, this workaround
can be removed.
Fixes the regression where rayon-based code (e.g., lopdf in PDF handling)
panicked on WASI after nightly-2025-12-10.
Before fix:
pthread_create returns EAGAIN (error code 6)
ThreadPoolBuildError { kind: IOError(Os { code: 6,
kind: WouldBlock, message: "Resource temporarily unavailable" }) }
After fix:
Thread::new returns Err(io::Error::UNSUPPORTED_PLATFORM)
Libraries can gracefully handle the lack of threading support
xous: fix build due to function and feature name changes
This tracks a rename of `panic_unwind` to `panic-unwind`, as well as the removal of `abort_internal` as a function.
This also fixes an incorrect function name from when `rust_main_thread_not_inlined` was added.
This fixes some fallout from 147572 where the `thread::sleep` function
is is broken on `wasm32-wasip2` after that PR. The cause for this is a
broken implementation of `nanosleep` in wasi-libc itself which is being
fixed in WebAssembly/wasi-libc/696. Similar to 149999 this avoids the
problematic function for now while the wasi-libc changes take some time
to propagate into a wasi-sdk release.
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.
Motor OS was added as a no-std Tier-3 target in
https://github.com/rust-lang/rust/pull/146848
as x86_64-unknown-motor.
This patch/PR adds the std library for Motor OS.
While the patch may seem large, all it does is proxy
std pal calls to moto-rt. When there is some non-trivial
code (e.g. thread::spawn), it is quite similar, and often
identical, to what other platforms do.
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This
follows in the footsteps of the previous `wasm32-wasip2` target and is
used to represent binding to the WASIp3 set of APIs managed by the WASI
subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized.
They're in the process of doing so and the current trajectory is to have
the APIs published in December of this year. The goal here is to get the
wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as
`wasm32-wasip2` except that `target_env = "p3"` is specified. This
indicates to crates in the ecosystem that WASIp3 APIs should be used,
such as the [`wasip3` crate]. Over time this target will evolve as
implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're
finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively
which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added
to the WASIp3-track of targets to enable using `std::thread`, for
example, on this target.
These changes are all expected to be non-breaking changes for users of
this target. Runtimes supporting WASIp3, currently Wasmtime and Jco,
support WASIp2 APIs as well and will work with components whether or not
they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This
means that changing the internal implementation details of libstd over
time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
Jan Sommer