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
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
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.
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.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Optionally add type names to `TypeId`s.
This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation.
It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see
<https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.)
Example usage and output:
```
fn main() {
use std::any::{Any, TypeId};
dbg!(TypeId::of::<usize>(), drop::<usize>.type_id());
}
```
```
TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize)
drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>)
```
Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.
Related issues:
* #68379
* #61533
The recent fixes to private dependencies exposed some cases in the UEFI
module where private dependencies are exposed in a public interface.
These do not need to be crate-public, so change them to `pub(crate)`.
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.
Organize `OsString`/`OsStr` shims
Synchronize the `bytes.rs` and `wtf8.rs` shims for `OsString`/`OsStr` so they're easier to diff between each other. This is mostly ordering items the same between the two. I tried to minimize moves and went for the average locations between the files.
With them in the same order, it is clear that `FromInner<_>` is not implemented for `bytes::Buf` and `Clone::clone_from` is not implemented for `wtf8::Buf`, but they are for the other. Fix that.
I added #[inline] to all inherent methods of the `OsString`/`OsStr` shims, because it seemed that was already the rough pattern. `bytes.rs` has more inlining than `wtf8.rs`, so I added the corresponding ones to `wtf8.rs`. Then, the common missing ones have no discernible pattern to me. They're not divided by non-allocating/allocating. Perhaps the pattern is that UTF-8 validation isn't inlined? Since these types are merely the inner values in `OsStr`/`OsString`, I put inline on all methods and let those public types dictate inlining. I have not inspected codegen or run benchmarks.
Also, touch up some (private) documentation comments.
r? ``````@ChrisDenton``````
Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants
This pull request adds the `MAX_LEN_UTF8` and `MAX_LEN_UTF16` constants as per #45795, gated behind the `char_max_len` feature.
The constants are currently applied in the `alloc`, `core` and `std` libraries.
Add a bullet point to `std::fs::copy`
I needed to copy a file but I got the following error:
```
Os { code: 2, kind: NotFound, message: "No such file or directory" }
```
After read the documentation, I though the error was generated by the `from` parameter, forgetting the `to` part. Anyway, I got the error because the parent folder of `to` didn't exist.
Even if the documentation explicitly saying `but is not limited to just these cases`, I would like to add this case because I spent 3 hours around it.
This PR just wants to put a mention about it.
