std: Fix size returned by UEFI tcp4 read operations
The read and read_vectored methods were returning the length of the input buffer, rather than the number of bytes actually read. Fix by changing read_inner to return the correct value, and have both read and read_vectored return that.
The read and read_vectored methods were returning the length of the
input buffer, rather than the number of bytes actually read. Fix by
changing read_inner to return the correct value, and have both read and
read_vectored return that.
std: sys: fs: uefi: Implement copy
- Using the implementation from sys::fs::common since ther is no built-in copy implementation in UEFI.
- Tested with OVMF on QEMU.
@rustbot label +O-UEFI
std: sys: fs: uefi: Implement File::flush
- Also forward fsync and datasync to flush. UEFI does not have anything separate for metadata sync.
@rustbot label +O-UEFI
Fix the connect_error test on FreeBSD 15+
On FreeBSD 15, the error code returned in this situation changed. It's now ENETUNREACH. I think that error code is reasonable, and it's documented for connect(2), so we should expect that it might be returned.
- Using the implementation from sys::fs::common since ther is no
built-in copy implementation in UEFI.
- Tested with OVMF on QEMU.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Remove std_detect_file_io and std_detect_dlsym_getauxval features
They were introduced back when std_detect was a standalone crate published to crates.io. The [motivation](https://github.com/rust-lang/stdarch/issues/655) for `std_detect_dlsym_getauxval` was to allow using `getauxval` without `dlopen` when statically linking musl, which we now unconditionally do for musl. And for `std_detect_file_io` to allow `no_std` usage, which std_detect now supports even with that feature enabled as it directly uses libc. This also prevents accidentally disabling runtime feature detection when using `cargo build -Zbuild-std -Zbuild-std-features=`
Implement create_dir_all() to operate iteratively instead of recursively
The current implementation of `create_dir_all(...)` in std::fs operates recursively. As mentioned in rust-lang/rust#124309, this could run into a stack overflow with big paths. To avoid this stack overflow issue, this PR implements the method in an iterative manner, preserving the documented behavior of:
```
Recursively create a directory and all of its parent components if they are missing.
This function is not atomic. If it returns an error, any parent components it was able to create will remain.
If the empty path is passed to this function, it always succeeds without creating any directories.
```
Fix std::fs::copy on WASI by setting proper OpenOptions flags
When PR rust-lang/rust#147572 switched WASI to use Unix-style filesystem APIs, the open_to_and_set_permissions function for WASI was implemented to call OpenOptions::new().open() without setting any access mode flags.
This causes std::fs::copy to fail with the error:
"must specify at least one of read, write, or append access"
The fix is to explicitly set .write(true), .create(true), and .truncate(true) on the OpenOptions, matching the behavior of the non-WASI Unix implementation but without the permission handling that WASI doesn't support.
Minimal reproduction:
```rs
fn main() {
std::fs::write("/src.txt", b"test").unwrap();
match std::fs::copy("/src.txt", "/dst.txt") {
Ok(_) => println!("PASS: fs::copy works!"),
Err(e) => println!("FAIL: {}", e),
}
}
```
# Compile and run:
rustc +nightly --target wasm32-wasip2 test.rs -o test.wasm
wasmtime -S cli --dir . test.wasm
# Before fix: FAIL: must specify at least one of read, write, or append access
# After fix: PASS: fs::copy works!
Note: The existing test library/std/src/fs/tests.rs::copy_file_ok would have caught this regression if the std test suite ran on WASI targets. Currently std tests don't compile for wasm32-wasip2 due to Unix-specific test code in library/std/src/sys/fd/unix/tests.rs.
Fixes the regression introduced in nightly-2025-12-10.
r? @alexcrichton
- Make flush a noop since it is only for buffered writers.
- Also forward fsync to datasync. UEFI does not have anything
separate for metadata sync.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
When PR #147572 switched WASI to use Unix-style filesystem APIs, the
open_to_and_set_permissions function for WASI was implemented to call
OpenOptions::new().open() without setting any access mode flags.
This causes std::fs::copy to fail with the error:
"must specify at least one of read, write, or append access"
The fix is to explicitly set .write(true), .create(true), and
.truncate(true) on the OpenOptions, matching the behavior of the
non-WASI Unix implementation but without the permission handling
that WASI doesn't support.
Minimal reproduction:
fn main() {
std::fs::write("/src.txt", b"test").unwrap();
match std::fs::copy("/src.txt", "/dst.txt") {
Ok(_) => println!("PASS: fs::copy works!"),
Err(e) => println!("FAIL: {}", e),
}
}
# Compile and run:
rustc +nightly --target wasm32-wasip2 test.rs -o test.wasm
wasmtime -S cli --dir . test.wasm
# Before fix: FAIL: must specify at least one of read, write, or append access
# After fix: PASS: fs::copy works!
Note: The existing test library/std/src/fs/tests.rs::copy_file_ok
would have caught this regression if the std test suite ran on WASI
targets. Currently std tests don't compile for wasm32-wasip2 due to
Unix-specific test code in library/std/src/sys/fd/unix/tests.rs.
Fixes the regression introduced in nightly-2025-12-10.
Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency`
Since it's a bit annoying to have different names for the same thing.
My understanding is that this is just internal stuff that is not part of any public API even tough rust-analyzer knows about it.
Continuation of
- https://github.com/rust-lang/rust/pull/139084.
Discovered while investigating
- https://github.com/rust-lang/rust/issues/150514
std: sys: fs: uefi: Implement remove_dir_all
- Using the implementation from sys::fs::common since UEFI does not have a built-in for this functionality.
@rustbot label +O-UEFI
They were introduced back when std_detect was a standalone crate
published to crates.io. The motivation for std_detect_dlsym_getauxval
was to allow using getauxval without dlopen when statically linking
musl, which we now unconditionally do for musl. And for
std_detect_file_io to allow no_std usage, which std_detect now supports
even with that feature enabled as it directly uses libc. This also
prevents accidentally disabling runtime feature detection when using
cargo build -Zbuild-std -Zbuild-std-features=
On FreeBSD 15, the error code returned in this situation changed. It's
now ENETUNREACH. I think that error code is reasonable, and it's
documented for connect(2), so we should expect that it might be
returned.
use PIDFD_GET_INFO ioctl when available
This way using pidfd_spawnp won't have to rely on procfs, avoiding an unpleasant edge-case where the child is spawned but we can't get the pid. And pidfd.{try_}wait will be able to return the exit status even after a process has been reaped. At least on newer kernels.
Tracking issue: https://github.com/rust-lang/rust/issues/82971
This way using pidfd_spawnp won't have to rely on procfs, avoiding an unpleasant edge-case
where the child is spawned but we can't get the pid.
And `pidfd.{try_}wait` will be able to return the exit status even after a process has been reaped.
At least on newer kernels.
`oneshot` Channel
Tracking Issue: https://github.com/rust-lang/rust/issues/143674
This PR adds an experimental `oneshot` module.
Before talking about the API itself, I would prefer to get some of these questions below out of the way first. And as discussed in the [ACP](https://github.com/rust-lang/libs-team/issues/610) it would be
# Unresolved Questions
- [x] ~~Why exactly is it okay for `Sender` to be `Sync`? Or basically, how do we boil down the discussion in https://github.com/rust-lang/rust/pull/111087 into a comment for the `unsafe impl<T: Send> Sync for Sender<T> {}`?~~
- [x] ~~Why is `mpsc::Receiver` `!Sync` but `mpmc::Receiver` is `Sync`? Should `oneshot::Receiver` be `Sync` or not?~~
- [ ] Should this PR try to add an `is_ready` method as proposed in the tracking issue? If so, then the surface of this PR would likely need to increase to add a `pub(crate) fn is_disconnected` method to `mpmc` (might even be a good idea to add that to all 3 channel flavors).
- [ ] In a similar vein to the previous question, should the first internal implementation simply be a wrapper around `mpmc`, or should it be a wrapper around the internal crossbeam implementation?
- [ ] Should the `Sender` and `Receiver` operations be methods or associated methods? So `sender.send(msg)` or `Sender::send(sender, msg)`? The method syntax is more consistent with the rest of the ecosystem (namely `tokio`)
std: sys: fs: uefi: Implement rename
- Using the file_name field in `EFI_FILE_INFO` works for renaming, even when changing directories.
- Does not work for cross-device rename, but that is already expected behaviour according to the docs:
"This will not work if the new name is on a different mount point."
- Also add some helper code for dealing with UefiBox<file::Info>.
- Tested using OVMF in qemu.
- edk2 implementation of the same: 66346d5ede/ShellPkg/Library/UefiShellLevel2CommandsLib/Mv.c (L455)
``@rustbot`` label +O-UEFI
- Using the implementation from sys::fs::common since UEFI does not have
a built-in for this functionality.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
mutex.rs: remove needless-maybe-unsized bounds
Fixes for:
```text
warning: `?Sized` bound is ignored because of a `Sized` requirement
--> library/std/src/sync/nonpoison/mutex.rs:425:9
|
425 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^
|
note: `T` cannot be unsized because of the bound
--> library/std/src/sync/nonpoison/mutex.rs:425:18
|
425 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^^
= note: ...because `Default` has the bound `Sized`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_maybe_sized
= note: `-W clippy::needless-maybe-sized` implied by `-W clippy::suspicious`
= help: to override `-W clippy::suspicious` add `#[allow(clippy::needless_maybe_sized)]`
help: change the bounds that require `Sized`, or remove the `?Sized` bound
|
425 - impl<T: ?Sized + Default> Default for Mutex<T> {
425 + impl<T: Default> Default for Mutex<T> {
|
warning: `?Sized` bound is ignored because of a `Sized` requirement
--> library/std/src/sync/poison/mutex.rs:691:9
|
691 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^
|
note: `T` cannot be unsized because of the bound
--> library/std/src/sync/poison/mutex.rs:691:18
|
691 | impl<T: ?Sized + Default> Default for Mutex<T> {
| ^^^^^^^
= note: ...because `Default` has the bound `Sized`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_maybe_sized
help: change the bounds that require `Sized`, or remove the `?Sized` bound
|
691 - impl<T: ?Sized + Default> Default for Mutex<T> {
691 + impl<T: Default> Default for Mutex<T> {
```
std: sys: net: uefi: tcp: Initial TcpListener support
Add support for binding and accepting TCP4 connections.
While testing, the following network options were used with QEMU + OVMF: -nic user,hostfwd=tcp::12345-:12345
The default localhost address on qemu seems to be 10.0.2.15.
UEFI spec does not seem to state that the TCP Handle returned by the Accept method has a ServiceBinding Protocol. So have made the ServiceBinding Protocol optional.
cc `@nicholasbishop`
