The methods `Take::get_mut` and `Chain::get_mut` include comments
warning about modifying the I/O state of the underlying reader. However,
many readers (e.g. `File`) allow I/O using a shared reference (e.g.
`&File`). So, add the same caveat to the `get_ref` methods.
Fix: Map EOPNOTSUPP to ErrorKind::Unsupported on Unix
This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized.
Fixes#139803
std/thread: Use default stack size from menuconfig for NuttX
* Update comments to clarify the usage of zero as an indication for default stack size configuration
* Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform
This change improves clarity and consistency in stack size configuration across platforms.
std: sys: process: uefi: Use NULL stdin by default
According to the docs in `Command::output`:
> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing.
This was being violated by UEFI which was inheriting stdin by default.
While the docs don't explicitly state that the default should be NULL, the behaviour seems like reading from NULL.
UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` only provides support for reading 1 key press. This means that you either get an error, or it is assumed that the keypress was read successfully. So there is no way to have a successful read of length 0. Currently, I am returning UNSUPPORTED error when trying to read from NULL stdin. On linux however, you will get a read of length 0 for Null stdin.
One possible way to get around this is to translate one of the UEFI errors to a read 0 (Maybe unsupported?). It is also possible to have a non-standard error code, but well, not sure if we go that route.
Alternatively, if meaning of Stdio::Null is platform dependent, it should be fine to keep the current behaviour of returning an error.
cc ```@nicholasbishop``` ```@dvdhrm```
This change maps the EOPNOTSUPP errno value (95) to std::io::ErrorKind::Unsupported in the decode_error_kind function for Unix platforms. Previously, it was incorrectly mapped to ErrorKind::Uncategorized.
Fixes#139803
Stdio::MakePipe is not supported.
For Stdio::Null, return UNSUPPORTED. This is treated as read(0).
Additionally, have infinte loop on the notify function to prevent
wait_for_key from returning.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
According to the docs in `Command::output`:
> By default, stdout and stderr are captured (and used to provide the
resulting output). Stdin is not inherited from the parent and any attempt
by the child process to read from the stdin stream will result in the
stream immediately closing.
This was being violated by UEFI which was inheriting stdin by default.
While the docs don't explicitly state that the default should be NULL,
the behaviour seems like reading from NULL.
UEFI however, has a bit of a problem. The `EFI_SIMPLE_TEXT_INPUT_PROTOCOL`
only provides support for reading 1 key press. This means that you
either get an error, or it is assumed that the keypress was read
successfully. So there is no way to have a successful read of length 0.
Currently, I am returning UNSUPPORTED error when trying to read from
NULL stdin. On linux however, you will get a read of length 0 for Null
stdin.
One possible way to get around this is to translate one of the UEFI
errors to a read 0 (Maybe unsupported?). It is also possible to have a
non-standard error code, but well, not sure if we go that route.
Alternatively, if meaning of Stdio::Null is platform dependent, it
should be fine to keep the current behaviour of returning an error.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
* Update comments to clarify the usage of zero as an indication for default stack size configuration
* Adjust conditional compilation to reflect the changes in stack size handling for the NuttX platform
This change improves clarity and consistency in stack size configuration across platforms.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Use `with_native_path` for Windows
Ideally, each platform should use their own native path type internally. This will, for example, allow passing a UTF-16 string directly to `std::fs::File::open` and therefore avoid the need for allocating a new null-terminated wide string. However, doing that for every function and platform all at once makes for a large PR that is way too prone to breaking. So this just does some of the Windows parts.
As with the previous Unix PR (#138832) this is intended to be merely a refactoring so I've avoided anything that may require more substantial changes.
std: Fix build for NuttX targets
Fix std build for all NuttX targets. It is the single largest set of failures on <https://does-it-build.noratrieb.dev/>. Although, ESP-IDF also requires these same gates, there are other issues for those targets.
This can verified be running `x check library/std --target=` for all NuttX targets.
cc ``@no1wudi``
Rollup of 6 pull requests
Successful merges:
- #139107 (std: make `cmath` functions safe)
- #139607 (Add regression test for #127424)
- #139691 (Document that `opt-dist` requires metrics to be enabled)
- #139707 (Fix comment in bootstrap)
- #139708 (Fix name of field in doc comment)
- #139709 (bootstrap: fix typo in doc string)
r? `@ghost`
`@rustbot` modify labels: rollup
std: make `cmath` functions safe
The floating point intrinsics are more difficult, I'll probably wait until #119899 has merged before making them safe as well.
Update windows-bindgen to 0.61.0
This updates the automatically generate Windows API bindings. Not much changed this time:
- There's now `Default` implementations for many types, which is convenient. It does however conflict with one place where we implemented a non-zeroed default (to set the length field). But that's no big problem.
- The `--no-core` flag has been renamed to `--no-deps` to more accurately reflect its meaning (i.e. generate all necessary code without requiring additional dependencies).
- The `--link` flag allows us to set the location of the `link!` macro. Currently we use our workspace's `windows_targets` crate but we could move it into library/std using `--link`. However, this would need to be co-ordinated with the `backtrace` crate (which is a separate crate but included in std using `#[path]`). So I've left that for another time.
Try not to use verbatim paths in `Command::current_dir`
If possible, we should try not to use verbatim paths in `Command::current_dir`. It might work but it might also break code in the subprocess that assume the current directory isn't verbatim (including Windows APIs). cc ``@ehuss``
Side note: we now have a lot of ad-hoc fixes like this spread about the place. It'd be good to make a proper `WindowsPath` type that handles all this in one place. But that's a bigger job for another PR.
If possible, we should try not to use verbatim paths in Command::current_dir. It might work but it might also break code (including some Windows APIs) that assume the current directory isn't verbatim.
Trusty: Implement `write_vectored` for stdio
Currently, `write` for stdout and stderr on Trusty is implemented with the semantics of `write_all`. Instead, call the underlying syscall only once in `write` and use the default implementation of `write_all` like other platforms. Also, implement `write_vectored` by adding support for `IoSlice`.
Refactor stdin to reuse the unsupported type like https://github.com/rust-lang/rust/pull/136769.
It requires #138875 to fix the build for Trusty, though they do not conflict and can merge in either order.
cc `@randomPoison`
Fix std build for all NuttX targets. It is the single largest set of
failures on <https://does-it-build.noratrieb.dev/>. Although, ESP-IDF
also requires these same gates, there are other issues for those
targets.
This can verified be running `x check library/std --target=` for all
NuttX targets.
Rename internal module from `statik` to `no_threads`
This module is named in reference to the keyword, but the term is somewhat overloaded. Rename it to more clearly describe it and avoid the misspelling.
Move `fd` into `std::sys`
Move platform definitions of `fd` into `std::sys`, as part of https://github.com/rust-lang/rust/issues/117276.
Unlike other modules directly under `std::sys`, this is only available on some platforms and I have not provided a fallback abstraction for unsupported platforms. That is similar to how `std::os::fd` is gated to only supported platforms.
Also, fix the `unsafe_op_in_unsafe_fn` lint, which was allowed for the Unix fd impl. Since macro expansions from `std::sys::pal::unix::weak` trigger this lint, fix it there too.
cc `@joboet,` `@ChrisDenton`
try-job: x86_64-gnu-aux
This module is named in reference to the keyword, but the term is
somewhat overloaded. Rename it to more clearly describe it and avoid the
misspelling.
Expose algebraic floating point intrinsics
# Problem
A stable Rust implementation of a simple dot product is 8x slower than C++ on modern x86-64 CPUs. The root cause is an inability to let the compiler reorder floating point operations for better vectorization.
See https://github.com/calder/dot-bench for benchmarks. Measurements below were performed on a i7-10875H.
### C++: 10us ✅
With Clang 18.1.3 and `-O2 -march=haswell`:
<table>
<tr>
<th>C++</th>
<th>Assembly</th>
</tr>
<tr>
<td>
<pre lang="cc">
float dot(float *a, float *b, size_t len) {
#pragma clang fp reassociate(on)
float sum = 0.0;
for (size_t i = 0; i < len; ++i) {
sum += a[i] * b[i];
}
return sum;
}
</pre>
</td>
<td>
<img src="https://github.com/user-attachments/assets/739573c0-380a-4d84-9fd9-141343ce7e68" />
</td>
</tr>
</table>
### Nightly Rust: 10us ✅
With rustc 1.86.0-nightly (8239a37f9) and `-C opt-level=3 -C target-feature=+avx2,+fma`:
<table>
<tr>
<th>Rust</th>
<th>Assembly</th>
</tr>
<tr>
<td>
<pre lang="rust">
fn dot(a: &[f32], b: &[f32]) -> f32 {
let mut sum = 0.0;
for i in 0..a.len() {
sum = fadd_algebraic(sum, fmul_algebraic(a[i], b[i]));
}
sum
}
</pre>
</td>
<td>
<img src="https://github.com/user-attachments/assets/9dcf953a-2cd7-42f3-bc34-7117de4c5fb9" />
</td>
</tr>
</table>
### Stable Rust: 84us ❌
With rustc 1.84.1 (e71f9a9a9) and `-C opt-level=3 -C target-feature=+avx2,+fma`:
<table>
<tr>
<th>Rust</th>
<th>Assembly</th>
</tr>
<tr>
<td>
<pre lang="rust">
fn dot(a: &[f32], b: &[f32]) -> f32 {
let mut sum = 0.0;
for i in 0..a.len() {
sum += a[i] * b[i];
}
sum
}
</pre>
</td>
<td>
<img src="https://github.com/user-attachments/assets/936a1f7e-33e4-4ff8-a732-c3cdfe068dca" />
</td>
</tr>
</table>
# Proposed Change
Add `core::intrinsics::f*_algebraic` wrappers to `f16`, `f32`, `f64`, and `f128` gated on a new `float_algebraic` feature.
# Alternatives Considered
https://github.com/rust-lang/rust/issues/21690 has a lot of good discussion of various options for supporting fast math in Rust, but is still open a decade later because any choice that opts in more than individual operations is ultimately contrary to Rust's design principles.
In the mean time, processors have evolved and we're leaving major performance on the table by not supporting vectorization. We shouldn't make users choose between an unstable compiler and an 8x performance hit.
# References
* https://github.com/rust-lang/rust/issues/21690
* https://github.com/rust-lang/libs-team/issues/532
* https://github.com/rust-lang/rust/issues/136469
* https://github.com/calder/dot-bench
* https://www.felixcloutier.com/x86/vfmadd132ps:vfmadd213ps:vfmadd231ps
try-job: x86_64-gnu-nopt
try-job: x86_64-gnu-aux
ToSocketAddrs: fix typo
It's "a function", never "an function".
I noticed the same typo somewhere in the compiler sources so figured I'd fix it there as well.
Remove creation of duplicate `AnonPipe`
The `File` is unwrapped to a `Handle` into an `AnonPipe`, and then that `AnonPipe` was unwrapped to a `Handle` into another `AnonPipe`. The second operation is entirely redundant.
io: Avoid marking some bytes as uninit
These bytes were marked as uninit, which would cause them to be initialized multiple times even though it was not necessary.
