Add slice::rchunks(), rchunks_mut(), rchunks_exact() and rchunks_exact_mut()
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
----
The new iterators were motivated by a [comment](https://github.com/rust-lang/rust/issues/47115#issuecomment-424141121) by @DutchGhost.
~~~This currently includes the commits from https://github.com/rust-lang/rust/pull/54537 to not have to rename things twice or have merge conflicts. I'll force-push a new version of the branch ones those are in master.~~~
Also the stabilization tracking issue is just some number right now. I'll create the corresponding issue once this is reviewed and otherwise mergeable.
cc @DutchGhost
In the comments of (closed, defunct) pull request #54884, Mazdak
"Centril" Farrokhzad noted that must-use annotations didn't work on an
associated function (what other communities might call a "static
method"). Subsequent logging revealed that in this case we have a
`Def::Method`, whereas the lint pass was only matching on
`Def::Fn`. (One could argue that those def-names are thereby
misleading—must-use for self-ful methods have always worked—but
documenting or reworking that can be left to another day.)
Add doc comments about safest way to initialize a vector of zeros
This adds more information about the vec! macro as discussed in #54628. I think this is a good starting point, but I think additional detail is needed so that we can explain why vec! is safer than the alternatives.
Use MaybeUninit in liballoc
All code by @japaric. This is a re-submission of a part of https://github.com/rust-lang/rust/pull/53508 that hopefully does not regress performance.
This commit introduces language items for `Arc` and `Rc` so that types
can later be checked to be `Arc` or `Rc` in the NLL borrow checker. The
`lang` attribute is currently limited to `stage1` as it requires a
compiler built with knowledge of the expected language items.
Introduce the partition_dedup/by/by_key methods for slices
This PR propose to add three methods to the slice type, the `partition_dedup`, `partition_dedup_by` and `partition_dedup_by_key`. The two other methods are based on `slice::partition_dedup_by`.
These methods take a mutable slice, deduplicates it and moves all duplicates to the end of it, returning two mutable slices, the first containing the deduplicated elements and the second all the duplicates unordered.
```rust
let mut slice = [1, 2, 2, 3, 3, 2];
let (dedup, duplicates) = slice.partition_dedup();
assert_eq!(dedup, [1, 2, 3, 2]);
assert_eq!(duplicates, [3, 2]);
```
The benefits of adding these methods is that it is now possible to:
- deduplicate a slice without having to allocate and possibly clone elements on the heap, really useful for embedded stuff that can't allocate for example.
- not loose duplicate elements, because, when using `Vec::dedup`, duplicates elements are dropped. These methods add more flexibillity to the user.
Note that this is near a copy/paste of the `Vec::dedup_by` function, once this method is stable the goal is to replace the algorithm in `Vec` by the following.
```rust
pub fn Vec::dedup_by<F>(&mut self, same_bucket: F)
where F: FnMut(&mut T, &mut T) -> bool
{
let (dedup, _) = self.as_mut_slice().partition_dedup_by(same_bucket);
let len = dedup.len();
self.truncate(len);
}
```
This commit fixes a buffer overflow issue in the standard library
discovered by Scott McMurray where if a large number was passed to
`str::repeat` it may cause and out of bounds write to the buffer of a `Vec`.
This bug was accidentally introduced in #48657 when optimizing the
`str::repeat` function. The bug affects stable Rust releases 1.26.0 to
1.29.0. We plan on backporting this fix to create a 1.29.1 release, and
the 1.30.0 release onwards will include this fix.
The fix in this commit is to introduce a deterministic panic in the case of
capacity overflow. When repeating a slice where the resulting length is larger
than the address space, there’s no way it can succeed anyway!
The standard library and surrounding libraries were briefly checked to see if
there were othere instances of preallocating a vector with a calculation that
may overflow. No instances of this bug (out of bounds write due to a calculation
overflow) were found at this time.
Note that this commit is the first steps towards fixing this issue,
we'll be making a formal post to the Rust security list once these
commits have been merged.
Update to a new pinning API.
~~Blocked on #53843 because of method resolution problems with new pin type.~~
@r? @cramertj
cc @RalfJung @pythonesque anyone interested in #49150
