std: move `kernel_copy` to `sys`
Part of rust-lang/rust#117276.
The current organisation of the `kernel_copy` mechanism used to specialise `io::copy` on Linux necessitated circular links between the `io::copy` module and the implementation in `sys::pal::unix::kernel_copy`, as well as presenting an exception to the tidy PAL rule that forbids OS-based `#[cfg]`s outside of `sys` and `os`.
This PR fixes this by moving `kernel_copy` to `sys` (as per rust-lang/rust#117276) and returning a `CopyState` from that function specifying whether `io::copy` should use its fallback. The `kernel_copy` function on other platforms just unconditionally returns `CopyState::Fallback`.
add must_use to extract_if methods
Also, mention the `.for_each(drop)` pattern in the documentation. One can't always use `retain` with a negated predicate as that does not have a range argument.
r? `@the8472`
Stabilize vec_into_raw_parts
This stabilizes `Vec::into_raw_parts()` and `String::into_raw_parts()` per FCP in https://github.com/rust-lang/rust/issues/65816#issuecomment-3517630971. While this _does not_ stabilize `Vec::into_parts()`, I fixed up the examples that said they were waiting for `vec_into_raw_parts`. As `Vec::from_parts()` and `Vec::into_parts()` are covered by the same feature `box_vec_non_null`, any doctest that uses `Vec::from_parts()` can also use `Vec::into_parts()` (and same for allocator-aware versions).
Closesrust-lang/rust#65816
``@rustbot`` modify labels: +T-libs-api
uefi: fs: Add file times plumbing
- Add plumbing to allow conversions to and from UEFI Time to Rust SystemTime.
- Also add FileTimes implementation.
cc `@nicholasbishop`
r? `@petrochenkov`
add missing s390x target feature to std detect test
Fix an oversight from https://github.com/rust-lang/rust/pull/145656, where the `is_s390x_feature_detected!` macro and some target features were stabilized, but other target features remain unstable under a new target feature name.
I tested this locally using a `stage1` build on the test file with the `s390x-unknown-linux-gnu` target.
cc ```@uweigand```
r? ```@Amanieu``` (or whoever really)
std: support `RwLock` and thread parking on TEEOS
Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms.
CC ``@petrochenkov`` ``@Sword-Destiny``
Enable std locking functions on AIX
This patch enables the std locking functions on AIX by including AIX on the list of supported targets for the locking functions. Excluding AIX from the std locking functions results to compilation errors such as: ("try_lock() not supported").
Fix rust stdlib build failing for VxWorks
Fixesrust-lang/rust#148125.
O_NOFOLLOW is not supported on VxWorks. All the other defines/functions have been added to libc(0cd5032671)
This patch enables the std locking functions on AIX by including AIX on the list
of supported targets for the locking functions. Excluding AIX from the std
locking functions results to compilation errors such as: ("try_lock() not supported").
library: std: sys: net: uefi: tcp: Implement write_vectored
- A working vectored write implementation for TCP4.
- Also introduces a small helper UefiBox intended to be used with heap allocated UEFI DSTs.
- Tested on OVMF
cc ```@nicholasbishop```
Fix documentation for std::panic::update_hook
The equivalent code given in the documentation of `std::panic::update_hook`[^1] does not compile:
* `set_hook` expects a boxed function
* Missing closing delimiter for the closure
[^1]: rust-lang/rust#92649
Ignore unix socket related tests for VxWorks
Unix Sockets are not implemented in VxWorks, and therefore, ignore testcases related to UnixDatagram, UnixListener and UnixStream.
std: don't leak the thread closure if destroying the thread attributes fails
The comment about double-free is wrong – we can safely drop both the thread attributes and the thread closure. Here, I've used `DropGuard` for the attributes and moved the `Box::into_raw` to just before the `pthread_create`.
- A working vectored write implementation for TCP4.
- Also introduces a small helper UefiBox intended to be used with heap
allocated UEFI DSTs.
- Tested on OVMF
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#135602 (Tweak output of missing lifetime on associated type)
- rust-lang/rust#139751 (Implement pin-project in pattern matching for `&pin mut|const T`)
- rust-lang/rust#142682 (Update bundled musl to 1.2.5)
- rust-lang/rust#148171 (Simplify code to generate line numbers in highlight)
- rust-lang/rust#148263 (Unpin `libc` and `rustix` in `compiler` and `rustbook`)
- rust-lang/rust#148301 ([rustdoc search] Include extern crates when filtering on `import`)
- rust-lang/rust#148330 (Don't require dlltool with the dummy backend on MinGW)
- rust-lang/rust#148338 (cleanup: upstream dropped amx-transpose functionality)
- rust-lang/rust#148340 (Clippy subtree update)
- rust-lang/rust#148343 (`nonpoison::Condvar` should take `MutexGuard` by reference)
r? `@ghost`
`@rustbot` modify labels: rollup
Since non-poisoning `Condvar` take non-poisoing `Mutex`es when
`wait`ing, we do not need to take by ownership since a poison error
cannot occur while we wait.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Setup for writing different tests for the `nonpoison::Condvar` since it
will have a different API.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Enable file locking support in illumos
https://github.com/rust-lang/rust/pull/132977 introduced an allow-list of targets supporting file locking, but forgot to add illumos to it (which introduced support for it in ~2015). `File::lock` and friends are now stable, and the ecosystem is slowly replacing custom libc calls with the standard library. Crucially, in 1.91 both Cargo and bootstrap switched to `File::lock`, both breaking build directory locking.
This PR enables file locking on illumos. Fixes https://github.com/rust-lang/rust/issues/146312.
Use fstatat() in DirEntry::metadata on Apple platforms
Apple supports `fstatat` on macOS >=10.10 ([source](https://gitlab.gnome.org/GNOME/glib/-/issues/2203)), and according to [Platform Support](https://doc.rust-lang.org/beta/rustc/platform-support.html) the oldest supported version is 10.12.
Google says iOS >=10 supports `fstatat` but doesn't provide a source. [*-apple-ios](https://doc.rust-lang.org/beta/rustc/platform-support/apple-ios.html#os-version) says the minimum supported iOS version is 10.0.
Unsure about tvOS, watchOS and visionOS, hoping CI can confirm this.
I am testing with [fastdu](https://github.com/jesseschalken/fastdu) which is effectively a stress test for `DirEntry::metadata`. In one test this provides a **1.13x** speedup.
```
$ hyperfine --warmup 1 'target/release/fastdu testdir' 'fastdu testdir'
Benchmark 1: target/release/fastdu testdir
Time (mean ± σ): 154.6 ms ± 17.4 ms [User: 31.7 ms, System: 187.6 ms]
Range (min … max): 148.4 ms … 225.5 ms 19 runs
Benchmark 2: fastdu testdir
Time (mean ± σ): 175.3 ms ± 15.8 ms [User: 50.0 ms, System: 196.2 ms]
Range (min … max): 165.4 ms … 211.7 ms 17 runs
Summary
target/release/fastdu testdir ran
1.13 ± 0.16 times faster than fastdu testdir
```
You can also reproduce a speedup with a program like this (providing a directory with many entries):
```rust
fn main() {
let args: Vec<_> = std::env::args_os().collect();
let dir: PathBuf = args[1].clone().into();
for entry in dir.read_dir().as_mut().unwrap() {
let entry = entry.as_ref().unwrap();
let metadata = entry.metadata();
let metadata = metadata.as_ref().unwrap();
println!("{} {}", metadata.len(), entry.file_name().display());
}
}
```
```
$ hyperfine './target/release/main testdir' './main testdir'
Benchmark 1: ./target/release/main testdir
Time (mean ± σ): 148.3 ms ± 5.2 ms [User: 23.1 ms, System: 122.9 ms]
Range (min … max): 145.2 ms … 167.2 ms 19 runs
Benchmark 2: ./main testdir
Time (mean ± σ): 164.4 ms ± 9.5 ms [User: 32.6 ms, System: 128.8 ms]
Range (min … max): 158.5 ms … 199.5 ms 17 runs
Summary
./target/release/main testdir ran
1.11 ± 0.07 times faster than ./main testdir
```
