Deprecate [T]::rotate in favor of [T]::rotate_{left,right}.
Background
==========
Slices currently have an **unstable** [`rotate`] method which rotates
elements in the slice to the _left_ N positions. [Here][tracking] is the
tracking issue for this unstable feature.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
Proposal
========
Deprecate the [`rotate`] method and introduce `rotate_left` and
`rotate_right` methods.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_left(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_right(2);
assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']);
```
Justification
=============
I used this method today for my first time and (probably because I’m a
naive westerner who reads LTR) was surprised when the docs mentioned that
elements get rotated in a left-ward direction. I was in a situation
where I needed to shift elements in a right-ward direction and had to
context switch from the main problem I was working on and think how much
to rotate left in order to accomplish the right-ward rotation I needed.
Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts
right-ward. Both of their implementations allow passing negative numbers
to shift in the opposite direction respectively. The current `rotate`
implementation takes an unsigned integer argument which doesn't allow
the negative number behavior.
Introducing `rotate_left` and `rotate_right` would:
- remove ambiguity about direction (alleviating need to read docs 😉)
- make it easier for people who need to rotate right
[`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate
[tracking]: https://github.com/rust-lang/rust/issues/41891
doc: improve None condition doc for `checked_div` and `checked_rem`
This commit improves the condition mentioned in the docs for which `checked_div` and `checked_rem` return `None`.
For signed division, the commit changes "the operation results in overflow" to "the division results in overflow", otherwise there is room for misinterpretation for `checked_rem`: Without considering overflow, `MIN % -1` would be simply zero, allowing the misinterpretation that "the operation" does not result in overflow in this case. This ambiguity is removed using "when the division results in overflow".
For unsigned division, the condition for `None` should be simply when `rhs == 0`, as no other overflow is possible.
Bump to 1.25.0
* Bump the release version to 1.25
* Bump the bootstrap compiler to the recent beta
* Allow using unstable rustdoc features on beta - this fix has been applied to
the beta branch but needed to go to the master branch as well.
Equivalent example for ? operator
The example with the ? operator in the documentation for try! macro was missing file.write_all.
Now all three examples are consistent.
Correct a few stability attributes
* The extra impls for `ManuallyDrop` were added in #44310 which was only stabilised in 1.22.0.
* The impls for `SliceIndex` were stabilised in #43373 but as `RangeInclusive` and `RangeToInclusive` are still unstable the impls should remain unstable.
* The `From` impls for atomic integers were added in #45610 but most atomic integers are still unstable.
* The `shared_from_slice2` impls were added in #45990 but they won't be stable until 1.24.0.
* The `Mutex` and `RwLock` impls were added in #46082 but won't be stable until 1.24.0.
* Bump the release version to 1.25
* Bump the bootstrap compiler to the recent beta
* Allow using unstable rustdoc features on beta - this fix has been applied to
the beta branch but needed to go to the master branch as well.
Use memchr for str::find(char)
This is a 10x improvement for searching for characters.
This also contains the patches from https://github.com/rust-lang/rust/pull/46713 . Feel free to land both separately or together.
cc @mystor @alexcrichton
r? @bluss
fixes#46693
Add a tidy check for missing or too many trailing newlines.
I've noticed recently there are lots of review comments requesting to fix trailing newlines. If this is going to be an official style here, it's better to let the CI do this repetitive check.
Add "Basic Usage" to int min_value and max_value docs
This adds "Basic Usage:" to the docs of `min_value` and `max_value`, which makes it consistent with docs of other integer methods.
Background
==========
Slices currently have an unstable [`rotate`] method which rotates
elements in the slice to the _left_ N positions. [Here][tracking] is the
tracking issue for this unstable feature.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
Proposal
========
Deprecate the [`rotate`] method and introduce `rotate_left` and
`rotate_right` methods.
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_left(2);
assert_eq!(a, ['c', 'd', 'e', 'f', 'a', 'b']);
```
```rust
let mut a = ['a', 'b' ,'c', 'd', 'e', 'f'];
a.rotate_right(2);
assert_eq!(a, ['e', 'f', 'a', 'b', 'c', 'd']);
```
Justification
=============
I used this method today for my first time and (probably because I’m a
naive westerner who reads LTR) was surprised when the docs mentioned that
elements get rotated in a left-ward direction. I was in a situation
where I needed to shift elements in a right-ward direction and had to
context switch from the main problem I was working on and think how much
to rotate left in order to accomplish the right-ward rotation I needed.
Ruby’s `Array.rotate` shifts left-ward, Python’s `deque.rotate` shifts
right-ward. Both of their implementations allow passing negative numbers
to shift in the opposite direction respectively.
Introducing `rotate_left` and `rotate_right` would:
- remove ambiguity about direction (alleviating need to read docs 😉)
- make it easier for people who need to rotate right
[`rotate`]: https://doc.rust-lang.org/std/primitive.slice.html#method.rotate
[tracking]: https://github.com/rust-lang/rust/issues/41891
Convert warning about `*const _` to a future-compat lint
#46664 was merged before I could convert the soft warning about method lookup on `*const _` into a future-compatibility lint. This PR makes that change.
fixes#46837
tracking issue for the future-compatibility lint: #46906
r? @arielb1
docs: do not call integer overflows as underflows
In the API docs, integer overflow is sometimes called underflow. Underflow is really when the magnitude of a floating-point number is too small so the number underflows to subnormal or zero. With integers it is always overflow, even if the expected result is less than the minimum number that can be represented.
docs(slice): Clarification in binary_search_by
This PR ~fixes a small comment typo~ adds some clarification to a half-open interval in the `binary_search_by` function in `slice`.
Make fmt::DebugList and friends forward formatting parameters
For example, formatting slice of integers with `{:04?}` should zero-pad each integer.
This also affects every use of `#[derive(Debug)]`.
Move PhantomData<T> from Shared<T> to users of both Shared and #[may_dangle]
After discussing https://github.com/rust-lang/rust/issues/27730#issuecomment-316432083 today with @pnkfelix and @Gankro, we concluded that it’s ok for drop checking not to be much smarter than the current `#[may_dangle]` design which requires an explicit unsafe opt-in.
