Change for-loop desugar to not borrow the iterator during the loop
This is enables the use of suspend points inside for-loops in movable generators. This is illegal in the current desugaring as `iter` is borrowed across the body.
Add an in-place rotate method for slices to libcore
A helpful primitive for moving chunks of data around inside a slice.
For example, if you have a range selected and are drag-and-dropping it somewhere else (Example from [Sean Parent's talk](https://youtu.be/qH6sSOr-yk8?t=560)).
(If this should be an RFC instead of a PR, please let me know.)
Edit: changed example
RangeFrom should have an infinite size_hint
Before,
```rust
(0..).take(4).size_hint() == (0, Some(4))
```
With this change,
```rust
(0..).take(4).size_hint() == (4, Some(4))
```
Clarify the docs for align_of and its variants
It's okay to have unaligned raw pointers and then use `ptr::write_unaligned` and `ptr::read_unaligned`.
However, using unaligned `&T` and `&mut T` would be undefined behavior.
The current documentation seems to indicate that everything has to be aligned, but in reality only references do. This PR changes the text of docs accordingly.
r? @sfackler
Clarify docs on implementing Into.
This was suggested by @dtolnay in #40380.
This explicitly clarifies in what circumstances you should implement `Into` instead of `From`.
Override size_hint and propagate ExactSizeIterator for iter::StepBy
Generally useful, but also a prerequisite for moving a bunch of unit tests off `Range*::step_by`.
A small non-breaking subset of https://github.com/rust-lang/rust/pull/42110 (which I closed).
Includes two small documentation changes @ivandardi requested on that PR.
r? @alexcrichton
Docs: impls of PartialEq/PartialOrd/Ord must agree
Fixes#41270.
This PR brings two improvements to the docs:
1. Docs for `PartialEq`, `PartialOrd`, and `Ord` clarify that their implementations must agree.
2. Fixes a subtle bug in the Dijkstra example for `BinaryHeap`, where the impls are inconsistent.
Thanks @Rufflewind for spotting the bug!
r? @alexcrichton
cc @frankmcsherry
Make RangeInclusive just a two-field struct
Not being an enum improves ergonomics and consistency, especially since NonEmpty variant wasn't prevented from being empty. It can still be iterable without an extra "done" bit by making the range have !(start <= end), which is even possible without changing the Step trait.
Implements merged https://github.com/rust-lang/rfcs/pull/1980; tracking issue https://github.com/rust-lang/rust/issues/28237.
This is definitely a breaking change to anything consuming `RangeInclusive` directly (not as an Iterator) or constructing it without using the sugar. Is there some change that would make sense before this so compilation failures could be compatibly fixed ahead of time?
r? @aturon (as FCP proposer on the RFC)
