Minor internal comments fix for `BufRead::read_line`
Just a little fix that came up while I was reading through this source code, and had to search for a few minutes to find out what was actually *meant* here.
- UEFI device path is a series of nodes layed out in a contiguous memory
region. So it makes sense to use Iterator abstraction for modeling
DevicePaths
- This PR has been split off from #135368 for easier review. The allow
dead_code will be removed in #135368
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
LLVM has crashes at some `half` operations when built with assertions
enabled if fp-armv8 is not available [1]. Things seem to usually work,
but we are reaching LLVM undefined behavior so this needs to be
disabled.
[1]: https://github.com/llvm/llvm-project/issues/129394
- Some UEFI protocols such as TCP4, TCP6, UDP4, UDP6, etc are managed by
service binding protocol.
- A new instance of such protocols is created and destroyed using the
corresponding service binding protocol.
- This PR adds abstractions to make using such protocols simpler using
Rust Drop trait.
- The reason to add these abstractions in a seperate PR from TCP4
Protocol is to make review easier.
[EFI_SERVICE_BINDING_PROTCOL](https://uefi.org/specs/UEFI/2.11/11_Protocols_UEFI_Driver_Model.html#efi-service-binding-protocol)
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Use correct error message casing for `io::const_error`s
Error messages are supposed to start with lowercase letters, but a lot of `io::const_error` messages did not. This fixes them to start with a lowercase letter.
I did consider adding a const check for this to the macro, but some of them start with proper nouns that make sense to uppercase them.
See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
Buffer::read_more() is supposed to refill the buffer without discarding
its contents, which are in the range `pos .. filled`.
It mistakenly borrows the range `pos ..`, fills that, and then
increments `filled` by the amount read. This overwrites the buffer's
existing contents and sets `filled` to a too-large value that either
exposes uninitialized bytes or walks off the end of the buffer entirely.
This patch makes it correctly fill only the unfilled portion of the
buffer, which should maintain all the type invariants and fix the test
failure introduced in commit b1196717fc.
This patch makes BufReader::peek()'s doctest call read_more() to refill
the buffer before the inner reader hits EOF. This exposes a bug in
read_more() that causes an out-of-bounds slice access and segfault.
The WTF-8 version of `OsString` tracks whether it is known to be valid
UTF-8 with its `is_known_utf8` field. Specialize `From<AsRef<OsStr>>` so
this can be set for UTF-8 string types.
When concatenating two WTF-8 strings, surrogate pairs at the boundaries
need to be joined. However, since UTF-8 strings cannot contain surrogate
halves, this check can be skipped when one string is UTF-8. Specialize
`OsString::push` to use a more efficient concatenation in this case.
Unfortunately, a specialization for `T: AsRef<str>` conflicts with
`T: AsRef<OsStr>`, so stamp out string types with a macro.
Error messages are supposed to start with lowercase letters, but a lot
of `io::const_error` messages did not. This fixes them to start with a
lowercase letter.
I did consider adding a const check for this to the macro, but some of
them start with proper nouns that make sense to uppercase them.
See https://doc.rust-lang.org/1.85.0/std/error/trait.Error.html
Fix Windows `Command` search path bug
Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,
```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();
// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```
This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).
This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.
r? libs-api
Return unexpected termination error instead of panicing in `Thread::join`
There is a time window during which the OS can terminate a thread before stdlib can retreive its `Packet`. Currently the `Thread::join` panics with no message in such an event, which makes debugging difficult; fixes#124466.
Add UTF-8 validation fast paths in `Wtf8Buf`
This adds two more fast paths for UTF-8 validation in `Wtf8Buf`, making use of the `is_known_utf8` flag added in https://github.com/rust-lang/rust/pull/96869 (Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8).
r? `@ChrisDenton`
Implement `read_buf` for zkVM stdin
For the zkVM, even when a guest buffer is uninitialized, from the host's perspective it is just a normal piece of memory which was initialized before letting the guest write into it. This makes `sys_read` safe to use with an uninitialized buffer. See https://github.com/risc0/risc0/issues/2853.
cc `@bobbobbio,` `@flaub`
r? `@Noratrieb`
Tracked in https://github.com/rust-lang/rust/issues/136756
Windows: use existing wrappers in `File::open_native`
Just a small improvement I've noticed - prevents accidents regarding `SetFileInformationByHandle` parameters.
Probably ``@ChrisDenton`` since we talked about it on discord :)
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic
LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that.
Suggested by `@hanna-kruppe` in https://github.com/rust-lang/rust/issues/136459; Cc `@tgross35`
try-job: test-various
There is a time window during which the OS can terminate a thread before stdlib
can retreive its `Packet`. Currently the `Thread::join` panics with no message
in such an event, which makes debugging difficult; fixes#124466.
More const {} init in thread_local
`const {}` in `thread_local!` gets an optimization just based on the syntax, rather than the expression being const-compatible. This is easy to miss, so I've added more examples to the docs.
I've also added `const {}` in a couple of places in std where this optimization has been missed.
Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix
As discussion in #136737.
- Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `sockaddr_storage` in `accept()` and `recvfrom()` since these functions fill in the address structure
- Replace `mem::zeroed()` with `MaybeUninit::uninit()` for `pthread_attr_t` in thread-related functions since `pthread_attr_init()` initializes the structure
- Add references to man pages to document this behavior
illumos has `posix_spawn`, and the very newest versions also have `_addchdir`,
so use that.
This is a nice ~4x performance improvement for process creation. My go-to as
usual is nextest against the clap repo, which acts as a stress test for process
creation -- with [this commit]:
```console
$ cargo nextest run -E 'not test(ui_tests) and not test(example_tests)'
before: Summary [ 1.747s] 879 tests run: 879 passed, 2 skipped
after: Summary [ 0.445s] 879 tests run: 879 passed, 2 skipped
```
[this commit]: fde45f9aea
Inject `compiler_builtins` during postprocessing and ensure it is made private
Follow up of https://github.com/rust-lang/rust/pull/135278
Do the following:
* Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST
* Do not make dependencies of `std` private by default (this was added in #135278)
* Make sure sysroot crates correctly mark their dependencies private/public
* Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified
* Do the `compiler_builtins` update that has been blocked on this
There is more detail in the commit messages. This includes the changes I was working on in https://github.com/rust-lang/rust/pull/136226.
try-job: test-various
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: i686-mingw-1
try-job: i686-mingw-2
Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7
Would otherwise fail there. The Windows7-specific parts were left pretty much untouched by the changes introduced by
51df98ddb0, so it is expected that these tests fail under Windows 7 as they were probably written to run under Windows 10+ only.
