Implement BitOr and BitOrAssign for the NonZero integer types
This provides overloaded operators for `NonZero$Int | NonZero$Int`, `NonZero$Int | $Int`, and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int`, for symmetry.
It's a pretty small conceptual addition, but is good becasue but avoids a case where the operation is obviously sound, but you'd otherwise need unsafe to do it.
In crates trying to minimize `unsafe` usage, this is unfortunate and makes working with `NonZero` types often not worth it, even if the operations you're doing are clearly sound.
I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information.
I'm not entirely confident what version I should have put down, so I followed https://www.whatrustisit.com. Hopefully it's correct for this.
Apologies in advance if this has come up before, but I couldn't find it.
Only the "first" iterator is actually set `None` when exhausted,
depending on whether you iterate forward or backward. This restores
behavior similar to the former `ChainState`, where it would transition
from `Both` to `Front`/`Back` and only continue from that side.
However, if you mix directions, then this may still set both sides to
`None`, totally fusing the iterator.
Fix bugs in Peekable and Flatten when using non-fused iterators
I fixed a couple of bugs with regard to the `Peekable` and `Flatten`/`FlatMap` iterators when the underlying iterator isn't fused. For testing, I also added a `NonFused` iterator wrapper that panics when `next` or `next_back` is called on an iterator that has returned `None` before, which will hopefully make it easier to spot these mistakes in the future.
### Peekable
`Peekable::next_back` was implemented as
```rust
self.iter.next_back().or_else(|| self.peeked.take().and_then(|x| x))
```
which is incorrect because when the `peeked` field is `Some(None)`, then `None` has already been returned from the inner iterator and what it returns from `next_back` can no longer be relied upon. `test_peekable_non_fused` tests this.
### Flatten
When a `FlattenCompat` instance only has a `backiter` remaining (i.e. `self.frontiter` is `None` and `self.iter` is empty), then `next` will call `self.iter.next()` every time, so the `iter` field needs to be fused. I fixed it by giving it the type `Fuse<I>` instead of `I`, I think this is the only way to fix it. `test_flatten_non_fused_outer` tests this.
Furthermore, previously `FlattenCompat::next` did not set `self.frontiter` to `None` after it returned `None`, which is incorrect when the inner iterator type isn't fused. I just delegated it to `try_fold` because that already handles it correctly. `test_flatten_non_fused_inner` tests this.
r? @scottmcm
fix aliasing violation in align_to_mut
Fixes https://github.com/rust-lang/rust/issues/68549
I decided to add the testcase here to make it all one PR, but if you prefer I can also add that test case in the Miri repo instead.
The hash tests were written before the assert_ne macro was added to the standard library. The assert_ne macro provides better output in case of a failure.
A `Duration` is created from a second and nanoseconds variable. The
documentation says: "This constructor will panic if the carry from the
nanoseconds overflows the seconds counter". This was, however, not tested
in the tests. I doubt the behavior will ever regress, but it is usually a
good idea to test all documented behavior.
Remove some unsound specializations
This removes the unsound and exploitable specializations in the standard library
* The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.
Step stage0 to bootstrap from 1.42
This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
Stabilize ptr::slice_from_raw_parts[_mut]
Closes#36925, the tracking issue.
Initial impl: #60667
r? @rust-lang/libs
In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
Add leading_ones and trailing_ones methods to the primitive integer types
I was surprised these were missing (given that `leading_zeros` and `trailing_zeros` exist), and they seem trivial and hopefully not controversial.
Note that there's some precedent in that `count_ones` and `count_zeros` are both supported even though only one of these has an intrinsic.
I'm not sure if these need a `rustc_const_unstable` flag (the tests don't seem to mind that it's missing). I just made them const, since there's not really any reason for these to be non-const when the `_zeros` variants are const.
Note: My understanding is trivial stuff like (hopefully) this can land without an RFC, but I'm not fully sure about the process though. Questions like "when does the tracking issue get filed?", are a total mystery to me. So, any guidance is appreciated, and sorry in advance if I should have gone through some more involved process for this.
Implement `DebugStruct::non_exhaustive`.
This patch adds a function (finish_non_exhaustive) to add ellipsis before the closing brace when formatting using `DebugStruct`.
## Example
```rust
#![feature(debug_non_exhaustive)]
use std::fmt;
struct Bar {
bar: i32,
hidden: f32,
}
impl fmt::Debug for Bar {
fn fmt(&self, fmt: &mut fmt::Formatter<'_>) -> fmt::Result {
fmt.debug_struct("Bar")
.field("bar", &self.bar)
.non_exhaustive(true) // Show that some other field(s) exist.
.finish()
}
}
assert_eq!(
format!("{:?}", Bar { bar: 10, hidden: 1.0 }),
"Bar { bar: 10, .. }",
);
```
Reset Formatter flags on exit from pad_integral
This fixes a bug where after calling pad_integral with appropriate flags, the
fill and alignment flags would be set to '0' and 'Right' and left as such even
after exiting pad_integral, which meant that future calls on the same Formatter
would get incorrect flags reported.
This is quite difficult to observe in practice, as almost all formatting
implementations in practice don't call `Display::fmt` directly, but rather use
`write!` or a similar macro, which means that they cannot observe the effects of
the wrong flags (as `write!` creates a fresh Formatter instance). However, we
include a test case.
A manual check leads me to believe this is the only case where we failed to reset the flags appropriately, but I could have missed something.
Don't require `allow_internal_unstable` unless `staged_api` is enabled.
#63770 changed `qualify_min_const_fn` to require `allow_internal_unstable` for *all* crates that used an unstable feature, regardless of whether `staged_api` was enabled or the `fn` that used that feature was stably const. In practice, this meant that every crate in the ecosystem that wanted to use nightly features added `#![feature(const_fn)]`, which skips `qualify_min_const_fn` entirely.
After this PR, crates that do not have `#![feature(staged_api)]` will only need to enable the feature they are interested in. For example, `#![feature(const_if_match)]` will be enough to enable `if` and `match` in constants. Crates with `staged_api` (e.g., `libstd`) require `#[allow_internal_unstable]` to be added to a function if it uses nightly features unless that function is also marked `#[rustc_const_unstable]`. This prevents proliferation of `#[allow_internal_unstable]` into functions that are not callable in a `const` context on stable.
r? @oli-obk (author of #63770)
cc @Centril
This flag opts out of the min-const-fn checks entirely, which is usually
not what we want. The few cases where the flag is still necessary have
been annotated.
This fixes a bug where after calling pad_integral with appropriate flags, the
fill and alignment flags would be set to '0' and 'Right' and left as such even
after exiting pad_integral, which meant that future calls on the same Formatter
would get incorrect flags reported.
This is quite difficult to observe in practice, as almost all formatting
implementations in practice don't call `Display::fmt` directly, but rather use
`write!` or a similar macro, which means that they cannot observe the effects of
the wrong flags (as `write!` creates a fresh Formatter instance). However, we
include a test case.
