Generalize IO Traits for `Arc<T>` where `&T: IoTrait`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Related: rust-lang/rust#94744
## Description
After experimenting with rust-lang/rust#155625, I noticed `Seek` and `SeekFrom` can almost be moved to `core::io`. Unfortunately, the implementation of `Seek` for `Arc<File>` is a blocker for such a move, since `Arc` is not a fundamental type. This PR attempts to resolve this potential blocker by replacing the implementation with a more general alternative. An internal trait `IoHandle` has been added which types can implement to opt-in to `Read`/`Write`/`Seek` implementations for `Arc<Self>` as long as `&Self` implements said trait. Note that `BufRead` is excluded as the signature for `fill_buf` would require returning from a temporary.
Since this "blanket" implementation only applies to a single type which already implements the same traits, I believe this should have no user-facing impact.
If this PR was merged, rust-lang/rust#134190 could be replaced with a 2 line PR:
```rust
impl IoHandle for TcpStream {}
impl IoHandle for UnixStream {}
```
Likewise for any other types, a table of which can be found [here](https://github.com/rust-lang/libs-team/issues/504#issuecomment-2539569736). This is out of scope for this PR to avoid the need for an ACP.
---
## Notes
* See [this comment](https://github.com/rust-lang/rust/issues/154046#issuecomment-4303975612) for further details.
* No AI tooling of any kind was used during the creation of this PR.
Added a marker trait `IoHandle` which can be used by the standard library to opt-in types to a blanket implementation of the various IO traits on `Arc<T>` where `&T: IoTrait` for some `IoTrait`.
The marker is required to avoid types like `Arc<[u8]>` being included, since they don't have interior mutability and would not give expected results.
This commit performs some minor update within the standard library for
the `wasm32-wasip3` target. This target is a tier 3 target currently due
to the WASIp3 specification not being officially released. This commit
adds a dependency from the standard library on the `wasip3` crate in the
same manner as the `wasip1` and `wasip2` crates that it already depends
on. The use-sites, for randomness and environment variables, are then
updated to handle the wasip2/wasip3 multiplexing.
Fix redundant boolean comparison in `Mutex::try_lock`
Simplify boolean return in `Mutex::try_lock`.
Replace `expr == false` with `!expr` for cleaner code.
Move `std::io::ErrorKind` to `core::io`
* Update `rustdoc-html` tests for the new path
* Add `core_io` feature to control stability. This replaces the use of `core_io_borrowed_buf` on the `core::io` module itself.
* Re-export `core::io::ErrorKind` in `std::io::error`
* Checking exhaustion will no longer be possible for `repr_bitpacked`. Moving `kind_from_prim` into an associated function, and setting it up to be moved into `core::io` as well.
* `ErrorKind::as_str` is private, but it's only usage is trivially replaced with `Display::fmt`
* The features io_error_inprogress, io_error_more, and io_error_uncategorized will all need to be enabled
std: Update dependency on `wasi` crate
This commit updates the crate dependency that the standard library has on the `wasi` crate. This is now updated to depending explicitly on the `wasip1` crate and the `wasip2` crate published on crates.io. These crates are managed in the [same location][repo] as the `wasi` crate and represent a different versioning scheme which doesn't require multi-version WASI support to require depending on the same crate at multiple versions. The code in libstd is updated to reference `wasip1` and `wasip2` directly as well.
[repo]: https://github.com/bytecodealliance/wasi-rs
Document why `layout.align() + layout.size()` doesn't overflow
This addition looks suspicious and is safety critical, but is saved by the weird `Layout` invariants.
std: fix HashMap RNG docs wording
Fixes a wording typo in the top-level HashMap docs.
Changed "random number coroutine" to "random number generator" in the seed entropy paragraph.
This section is security-relevant, and "generator" is the correct term in RNG context.
Testing:
- Not run locally (docs-only text change).
net::tcp/udp: fix docs about how set_nonblocking is implemented
`fcntl` `FIONBIO` doesn't even make sense, it should be `fcntl` `F_SETFL`. However, for some reason we are using `ioctl` by default -- except on Solaris where this doesn't seem to work very well.
Honestly what I would have expected is that we just always use `FileDesc::set_nonblocking` also for network sockets, but for some reason we don't and there are no comments explaining this choice. Cc @nikarh (for "vita") @joboet
docs: Fix typo in std/src/thready/scoped.rs
# Fix typo in std/src/thread/scoped.rs
## Why this pr
This PR fixes the typo mentioned in rust-lang/rust#155275.
I know this was originally fixed in rust-lang/rust#155325 and then in rust-lang/rust#155328.
But since the first issue was closed due to some ai slop and the second one was closed because the first one was already opened, it seems to me that this PR is still needed.
## What this pr does
This PR "just" fixes a typo inside the `std/src/thread/scoped.rs` file
Changing the comment from this:
```
/// borrow non-`'static` data from the outside the scope. See [`scope`] for
/// details.
```
to this:
```
/// borrow non-`'static` data from outside the scope. See [`scope`] for
/// details.
```
This commit updates the crate dependency that the standard library has
on the `wasi` crate. This is now updated to depending explicitly on the
`wasip1` crate and the `wasip2` crate published on crates.io. These
crates are managed in the [same location][repo] as the `wasi` crate and
represent a different versioning scheme which doesn't require
multi-version WASI support to require depending on the same crate at
multiple versions. The code in libstd is updated to reference `wasip1`
and `wasip2` directly as well.
[repo]: https://github.com/bytecodealliance/wasi-rs
abort in core
Implements `core::process::abort_immediate` as a wrapper around `intrinsics::abort`.
- tracking issue: https://github.com/rust-lang/rust/issues/154601
(This PR used to also add `core::process::abort`, but that's been deferred to a later addition.)
docs: clarify path search behavior in std::process::Command::new
the existing docs mentioned that `PATH` is searched in an "os defined way" and that it could be controlled by setting PATH on the command but never explained which `PATH` is actually used.
on unix the key thing to understand is that when you modify the childs environment (via `env()`, `env_remove()`, or `env_clear()`), the `PATH` search uses whatever `PATH` ends up in the child's environment not the parents. so if you call `env_clear()` and forget to set `PATH`, you don't get the parents `PATH` as a fallback; you get the OS default (typically `/bin:/usr/bin`) which often won't find what you need.
the three cases are now documented:
- unmodified env: child inherits parents `PATH`, that gets searched
- `PATH` explicitly set `via env()`: the new value is searched
- `PATH` removed (`env_clear` or `env_remove`): falls back to OS default, not the parents `PATH`
on windows rust resolves the executable before spawning rather than letting `CreateProcessW` do it. the search order is: childs `PATH` (if explicitly set) first then system-defined directories then the parents `PATH`. the existing note about issue rust-lang/rust#37519 is preserved.
limitations in this doc:
- the unix fallback path behavior ("typically `/bin:/usr/bin`") is verified for linux/glibc. behavior on macOS, BSD, and musl is similar in practice but not fully confirmed here.
- the windows search order is summarized as "system-defined directories" which actually includes the application directory (the directory of the calling process's executable) as a distinct step before the system dirs that detail is omitted for brevity.
- `posix_spawnp` `PATH` source (calling process environ vs envp argument) is ambiguous in the `POSIX` spec; the behavior here is inferred from the guard in `unix.rs` that bypasses `posix_spawn` when `PATH` has been modified.
closesrust-lang/rust#137286 (hopefully)
These comments appear to have been written before `BorrowedBuf`'s
init tracking was simplified in
https://github.com/rust-lang/rust/pull/150129. The `BufWriter` comment
of the usage within `BufWriter` will be handled separately.
Start using pattern types in libcore
cc rust-lang/rust#135996
Replaces the innards of `NonNull` with `*const T is !null`.
This does affect LLVM's optimizations, as now reading the field preserves the metadata that the field is not null, and transmuting to another type (e.g. just a raw pointer), will also preserve that information for optimizations. This can cause LLVM opts to do more work, but it's not guaranteed to produce better machine code.
Once we also remove all uses of rustc_layout_scalar_range_start from rustc itself, we can remove the support for that attribute entirely and handle all such needs via pattern types
Fix thread::available_parallelism on WASI targets with threads
The refactoring in ba462864f1 ("std: Use more unix.rs code on WASI targets") moved WASI from its own thread module into the shared unix.rs module. However, it did not carry over the available_parallelism() implementation for WASI with threads, causing it to fall through to the unsupported catch-all. This silently regressed the support originally added in f0b7008648.
Fix this by adding WASI to the standard UNIX cfg_select branch.
Depends on rust-lang/rust#155057 (Update libc to v0.2.184).
Add #![unstable_removed(..)] attribute to track removed features
Adds the #![unstable_removed(..)] attribute to enable tracking removed library features.
Produce an error when a removed attribute is used.
Add a test that it works.
For https://github.com/rust-lang/rust/issues/141617
r? @jyn514
Update hashbrown to 0.17
The main benefit of this update is to include one potential UB fix and one bug; relevant changelog entries:
* Fixed potential UB in `RawTableInner::fallible_with_capacity` (rust-lang/hashbrown#692)
* Fixed incorrect length if a hasher panics during rehash (rust-lang/hashbrown#710)
cc @Amanieu
Also cc @RalfJung who had also noticed the UB issue with `-Zmiri-recursive-validation`.
Jonathan Brouwer