Update mod comment
The comment of `ASCII_CASE_MASK` on line 477 is `If 6th bit is set ascii is lower case.` but the original comment of `*self ^ ((self.is_ascii_lowercase() as u8) * ASCII_CASE_MASK)` was `Toggle the fifth bit if this is a lowercase letter`
For these two methods, `other` is an ordinary unsigned integer, so it can be zero.
Since the sum of non-zero and zero is always non-zero, the safety argument
holds even when `other` is zero.
rustdoc: Remove space from fake-variadic fn ptr impls
before: `for fn (T₁, T₂, …, Tₙ) -> Ret`
after: `for fn(T₁, T₂, …, Tₙ) -> Ret`
I don't think we usually have spaces there, so it looks weird.
cc `@notriddle` since you added the space in https://github.com/rust-lang/rust/pull/98180 (or rather, added the feature with a space included).
Non null convenience ops
Based on https://github.com/rust-lang/libs-team/issues/251.
I went through all of the methods on `*mut` and added every method, which does not require additional safety conditions, to `NonNull`. (exceptions: `guaranteed_eq`, `guaranteed_ne`, `with_metadata_of`, it's unclear if they are useful here...)
I'm also not sure what types should the "second pointer parameter" be. `*mut`/`*const` might be more permissible, but given that `NonNull` doesn't coerce to them, it might also be annoying. For now I chose the "use `NonNull` everywhere" path, but I'm not sure it's the correct one...
<sub>I'm eepy, so I probably messed up somewhere while copying...</sub>
cc `@scottmcm`
r? libs-api
Add `debug_assert_nounwind` and convert `assert_unsafe_precondition`
`assert_unsafe_precondition` checks non-CTFE-evaluable conditions in runtime and performs no-op in compile time, while many of its current usage can be checked during const eval.
Fixes error count display is different when there's only one error left
Supersedes #114759
### What did I do?
I did the small change in `rustc_errors` by hand. Then I did the other changes in `/compiler` by hand, those were just find replace on `*.rs` in the workspace. The changes in run-make are find replace for `run-make` in the workspace.
All other changes are blessed using `x test TEST --bless`. I blessed the tests that were blessed in #114759.
### how to review this nightmare
ping bors with an `r+`. You should check that my logic is sound and maybe quickly scroll through the diff, but fully verifying it seems fairly hard to impossible. I did my best to do this correctly.
Thank you `@adrianEffe` for bringing this up and your initial implementation.
cc `@flip1995,` you said you want to do a subtree sync asap
cc `@RalfJung` maybe you want to do a quick subtree sync afterwards as well for Miri
r? `@WaffleLapkin`
Indicate that multiplication in Layout::array cannot overflow
Since https://github.com/rust-lang/rust/pull/113113, we have added a check that skips calling into the allocator at all if `capacity == 0`. The global, default allocator will not actually try to allocate though; it returns a dangling pointer explicitly. However, these two checks are not merged/deduplicated by LLVM and so we're comparing to zero twice whenever vectors are allocated/grown. Probably cheap, but also potentially expensive in code size and seems like an unfortunate miss.
This removes that extra check by telling LLVM that the multiplication as part of Layout::array can't overflow, turning the original non-zero value into a zero value afterwards. In my checks locally this successfully drops the duplicate comparisons.
See https://rust.godbolt.org/z/b6nPP9dcK for a code example.
```rust
pub fn foo(elements: usize) -> Vec<u32> {
Vec::with_capacity(elements)
}
```
r? `@scottmcm` since you touched this in a32305a80f - curious if you have thoughts on doing this / can confirm my model of this being correct.
Use an absolute path to the NUL device
While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
r? libs
Update windows-bindgen and define `INVALID_HANDLE_VALUE` ourselves
We generate bindings to the Windows API via the `windows-bindgen` crate, which is ultimately what's also used to generate the `windows-sys` and `windows` crates. However, there currently is some custom sauce just for std which makes it a bit different from the vanilla bindings. I would love for us to reduce and eventually remove the differences entirely so that std is using the exact same bindings as everyone else. Maybe in the future we can even just have a normal dependency on `windows-sys`.
This PR removes one of those special things. Our definition of `INVALID_HANDLE_VALUE` relies on an experimental nightly feature for strict provenance, so lets bring that back in house. It also excludes it from the codegen step though that isn't strictly necessary as we override it in any case.
This PR also updates windows-bingen to 0.52.0.
Improve rewind documentation
The persistent use of an internal cursor for readers is expected for buffer data types that aren't read all at once, but for files it leads to the confusing situation where calling `read_to_end` on the same file handle multiple times only returns the contents of the file for the first call. This PR adds a note to the documentation clarifying that in that case, `rewind()` must first be called.
I'm unsure if this is the right location for the docs update. Maybe it should also be duplicated on `File`?
This allows LLVM to optimize comparisons to zero before & after the
multiplication into one, saving on code size and eliminating an (always
true) branch from most Vec allocations.
kmc-solid: I/O safety
Adds the I/O safety API (#87329) for socket file descriptors in [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets. All new public items are gated by the `solid_ext` library feature.
This PR adds the following public types and traits:
std::os::solid::io::AsFd
std::os::solid::io::BorrowedFd
std::os::solid::io::OwnedFd
std::os::solid::prelude::AsFd (re-export)
std::os::solid::prelude::BorrowedFd (re-export)
std::os::solid::prelude::OwnedFd (re-export)
And trait implementations:
From<std::net::TcpListener> for std::os::solid::io::OwnedFd
From<std::net::TcpStream> for std::os::solid::io::OwnedFd
From<std::net::UdpSocket> for std::os::solid::io::OwnedFd
From<std::os::solid::io::OwnedFd> for std::net::TcpListener
From<std::os::solid::io::OwnedFd> for std::net::TcpStream
From<std::os::solid::io::OwnedFd> for std::net::UdpSocket
std::fmt::Debug for std::os::solid::io::BorrowedFd<'_>
std::fmt::Debug for std::os::solid::io::OwnedFd
std::io::IsTerminal for std::os::solid::io::BorrowedFd<'_>
std::io::IsTerminal for std::os::solid::io::OwnedFd
std::os::fd::AsRawFd for std::os::solid::io::BorrowedFd<'_>
std::os::fd::AsRawFd for std::os::solid::io::OwnedFd
std::os::fd::FromRawFd for std::os::solid::io::OwnedFd
std::os::fd::IntoRawFd for std::os::solid::io::OwnedFd
std::os::solid::io::AsFd for &impl std::os::solid::io::AsFd
std::os::solid::io::AsFd for &mut impl std::os::solid::io::AsFd
std::os::solid::io::AsFd for Arc<impl std::os::solid::io::AsFd>
std::os::solid::io::AsFd for Box<impl std::os::solid::io::AsFd>
std::os::solid::io::AsFd for Rc<impl std::os::solid::io::AsFd>
std::os::solid::io::AsFd for std::net::TcpListener
std::os::solid::io::AsFd for std::net::TcpStream
std::os::solid::io::AsFd for std::net::UdpSocket
std::os::solid::io::AsFd for std::os::solid::io::BorrowedFd<'_>
std::os::solid::io::AsFd for std::os::solid::io::OwnedFd
Taking advantage of the above change, this PR also refactors the internal details of `std::sys::solid::net` to match the design of other targets, e.g., by redefining `Socket` as a newtype of `OwnedFd`.
Fix some clippy lints for library/std/src/sys/windows
These issues were shown by running `x clippy` on `library/std` and filtering for `windows/` paths. I think running clippy on the full std would be great but I wanted to start smaller and with something that's hopefully easier to review. It'd be good to eventually run clippy in CI but that's a bigger conversation.
I've created separate commits for each clippy lint fixed (with the commit title set to the lint name) and reviewed the changes myself. Most of the fixes here are trivial.
r? libs
This is where our Windows API bindings previously (and incorrectly) used `*mut` instead of `*const` pointers. Now that the bindings have been corrected, the mutable references (which auto-convert to `*mut`) are unnecessary and we can use shared references.
feat: specialize `SpecFromElem` for `()`
# Description
This PR adds a specialization `SpecFromElem for ()` which allows to significantly reduce `vec![(), N]` time in debug builds (specifically, tests) turning it from observable $O(n)$ to $O(1)$.
# Observing the change
The problem this PR aims to fix explicitly is slow `vec![(), N]` on big `N`s which may appear in tests (see [Background section](#Background) for more details).
The minimal example to see the problem:
```rust
#![feature(test)]
extern crate test;
#[cfg(test)]
mod tests {
const HUGE_SIZE: usize = i32::MAX as usize + 1;
#[bench]
fn bench_vec_literal(b: &mut test::Bencher) {
b.iter(|| vec![(); HUGE_SIZE]);
}
#[bench]
fn bench_vec_repeat(b: &mut test::Bencher) {
b.iter(|| [(); 1].repeat(HUGE_SIZE));
}
}
```
<details><summary>Output</summary>
<p>
```bash
cargo +nightly test -- --report-time -Zunstable-options
Compiling huge-zst-vec-literal-bench v0.1.0 (/home/progrm_jarvis/RustroverProjects/huge-zst-vec-literal-bench)
Finished test [unoptimized + debuginfo] target(s) in 0.31s
Running unittests src/lib.rs (target/debug/deps/huge_zst_vec_literal_bench-e43b1ef287ba8b36)
running 2 tests
test tests::bench_vec_repeat ... ok <0.000s>
test tests::bench_vec_literal ... ok <14.382s>
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 14.38s
Doc-tests huge-zst-vec-literal-bench
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```
</p>
</details>
> [!IMPORTANT]
> This problem is only observable in Debug (unoptimized) builds, while Release (optimized) ones do not observe this problem. It still is worth fixing it, IMO, since the original scenario observes the problem in tests for which optimizations are disabled by default and it seems unreasonable to override this for the whole project while the problem is very local.
# Background
While working on a crate for a custom data format which has an `i32::MAX` limit on its list's sizes, I wrote the following test to ensure that this invariant is upheld:
```rust
#[test]
fn lists_should_have_i32_size() {
assert!(
RawNbtList::try_from(vec![(); i32::MAX as usize]).is_ok(),
"lists should permit the size up to {}",
i32::MAX
);
assert!(
RawNbtList::try_from(vec![(); i32::MAX as usize + 1]).is_err(),
"lists should have the size of at most {}",
i32::MAX
);
}
```
Soon I discovered that this takes $\approx 3--4s$ per assertion on my machine, almost all of which is spent on `vec![..]`.
While this would be logical for a non-ZST vector (which would require actual $O(n)$ allocation), here `()` was used intentionally considering that for ZSTs size-changing operations should anyway be $O(1)$ (at least from allocator perspective). Yet, this "overhead" is logical if we consider that in general case `clone()` (which is used by `Vec` literal) may have a non-trivial implementation and thus each element has to actually be visited (even if they occupy no space).
In my specific case, the following (contextual) equivalent solved the issue:
```rust
#[test]
fn lists_should_have_i32_size() {
assert!(
RawNbtList::try_from([(); 1].repeat(i32::MAX as usize)).is_ok(),
"lists should permit the size up to {}",
i32::MAX
);
assert!(
RawNbtList::try_from([(); 1].repeat(i32::MAX as usize + 1)).is_err(),
"lists should have the size of at most {}",
i32::MAX
);
}
```
which works since `repeat` explicitly uses `T: Copy` and so does not have to think about non-trivial `Clone`.
But it still may be counter-intuitive for users to observe such long time on the "canonical" vec literal thus the PR.
# Generic solution
This change is explicitly non-generic. Initially I considered it possible to implement in generically, but this would require the specialization to have the following type requirements:
- ✅ the type must be a ZST: easily done via
```rust
if core::mem::size_of::<T>() == 0 {
todo!("specialization")
}
```
or
```rust
use core::mem::SizedTypeProperties;
if T::IS_ZST {
todo!("specialization")
}
```
- :white_check_mark`: the type must implement `Copy`: implementable non-conflictable via a separate specialization:
```rust
trait IsCopyZst: Sized {
fn is_copy_zst() -> bool;
}
impl<T> IsCopyZst for T {
fn is_copy_zst() -> bool {
false
}
}
impl<T: Copy> IsCopyZst for T {
fn is_copy_zst() -> bool {
Self::IS_ZST
}
}
```
- ❌ the type should have a trivial `Clone` implementation: since `vec![t; n]` is specified to use `clone()`, we can only use this "performance optimization" when we are guaranteed that `clone()` does nothing except for copying.
The latter is the real blocker for a generic fix since I am unaware of any way to get this information in a compiler-guaranteed way.
While there may be a fix for this (my friend `@CertainLach` has suggested a potential solution by an perma-unstable fn in `Clone` like `is_trivially_cloneable()` defaulting to `false` and only overridable by `rustc` on derive), this is surely out of this PRs scope.
While a better approach would be to implement it for all ZSTs
which are `Copy` and have trivial `Clone`,
the last property cannot be detected for now.
Signed-off-by: Petr Portnov <me@progrm-jarvis.ru>
While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
Adjust frame IP in backtraces relative to image base for SGX target
This is followup to https://github.com/rust-lang/backtrace-rs/pull/566.
The backtraces printed by `panic!` or generated by `std::backtrace::Backtrace` in SGX target are not usable. The frame addresses need to be relative to image base address so they can be used for symbol resolution. Here's an example panic backtrace generated before this change:
```
$ cargo r --target x86_64-fortanix-unknown-sgx
...
stack backtrace:
0: 0x7f8fe401d3a5 - <unknown>
1: 0x7f8fe4034780 - <unknown>
2: 0x7f8fe401c5a3 - <unknown>
3: 0x7f8fe401d1f5 - <unknown>
4: 0x7f8fe401e6f6 - <unknown>
```
Here's the same panic after this change:
```
$ cargo +stage1 r --target x86_64-fortanix-unknown-sgx
stack backtrace:
0: 0x198bf - <unknown>
1: 0x3d181 - <unknown>
2: 0x26164 - <unknown>
3: 0x19705 - <unknown>
4: 0x1ef36 - <unknown>
```
cc `@jethrogb` and `@workingjubilee`
Add Seek::seek_relative
The `BufReader` struct has a `seek_relative` method because its `Seek::seek` implementation involved dumping the internal buffer (https://github.com/rust-lang/rust/issues/31100).
Unfortunately, there isn't really a good way to take advantage of that method in generic code. This PR adds the same method to the main `Seek` trait with the straightforward default method, and an override for `BufReader` that calls its implementation.
_Also discussed in [this](https://internals.rust-lang.org/t/add-seek-seek-relative/19546) internals.rust-lang.org thread._
Remove option_payload_ptr; redundant to offset_of
The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at https://github.com/rust-lang/rust/issues/106655#issuecomment-1790907626). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
Expose tests for {f32,f64}.total_cmp in docs
Expose tests for {f32,f64}.total_cmp in docs
Uncomment the helpful `assert_eq!` line, which is stripped out completely in docs, and leaves the reader to mentally play through the algorithm, or go to the playground and add a println!, to see what the result will be.
(If these tests are known to fail on some platforms, is there some mechanism to conditionalize this or escape the test so the `assert_eq!` source will be visible on the web? I am a newbie, which is why I was reading docs ;)
impl more traits for ptr::Alignment, add mask method
Changes:
* Adds `rustc_const_unstable` attributes where missing
* Makes `log2` method const
* Adds `mask` method
* Implements `Default`, which is equivalent to `Alignment::MIN`
No longer included in PR:
* Removes indirection of `AlignmentEnum` type alias (this was intentional)
* Implements `Display`, `Binary`, `Octal`, `LowerHex`, and `UpperHex` (should go through libs-api instead)
* Controversially implements `LowerExp` and `UpperExp` using `p` instead of `e` to indicate a power of 2 (also should go through libs-api)
Tracking issue for `ptr::Alignment`: #102070
Reenable effects in libcore
With #116670, #117531, and #117171, I think we would be comfortable with re-enabling the effects feature for more testing in libcore.
r? `@oli-obk`
cc `@fmease`
cc #110395
Add T: ?Sized to `RwLockReadGuard` and `RwLockWriteGuard`'s Debug impls.
For context, `MutexGuard` has `+ ?Sized` on its `Debug` impl, and all three have `+ ?Sized` on their `Display` impls.
It looks like the `?Sized` was just missed when the impls were added (the impl for `MutexGuard` was added in the same PR (https://github.com/rust-lang/rust/pull/38006) with support for `T: Debug + ?Sized`, and `RwLock*Guard`s did allow `T: ?Sized` types already); the `Display` impls were added later (https://github.com/rust-lang/rust/pull/42822) with support for `T: Debug + ?Sized` types.
I think this needs a T-libs-api FCP? I'm not sure if this also needs an ACP. If so I can make one.
These are changes to (stable) trait impls on stable types so will be insta-stable.
`@rustbot` label +T-libs-api
