This updates the `Extend` implementations to use `for_each` for many
collections: `BinaryHeap`, `BTreeMap`, `BTreeSet`, `LinkedList`, `Path`,
`TokenStream`, `VecDeque`, and `Wtf8Buf`.
Folding with `for_each` enables better performance than a `for`-loop for
some iterators, especially if they can just forward to internal
iterators, like `Chain` and `FlatMap` do.
Implement specialized nth_back() for Box and Windows.
Hi there, this is my first pull request to rust :-)
I started implementing some specializations for DoubleEndedIterator::nth_back() and these are the first two. The problem has been discussed in #54054 and nth_back() is tracked in #56995.
I'm stuck with the next implementation so I though I do a PR for the ones I'm confident with to get some feedback.
Move alloc::prelude::* to alloc::prelude::v1, make alloc a subset of std
This was one of the unresolved questions of https://github.com/rust-lang/rfcs/pull/2480. As the RFC says this is maybe not useful in the sense that we are unlikely to ever have a second version, but making the crate a true subset makes one less issue to think about if we stabilize it and later want to merge standard library crates and have Cargo feature flags to enable or disable parts of the `std` crate.
See also discussion in https://github.com/rust-lang/rust/pull/58175.
Also rename the feature gate and point to a dedicated tracking issue: https://github.com/rust-lang/rust/issues/58935
This was one of the unresolved questions of https://github.com/rust-lang/rfcs/pull/2480.
As the RFC says this is maybe not useful in the sense that we are unlikely
to ever have a second version, but making the crate a true subset
makes one less issue to think about if we stabilize it and later
want to merge standard library crates and have Cargo feature flags
to enable or disable parts of the `std` crate.
See also discussion in https://github.com/rust-lang/rust/pull/58175
In bluss/indexmap#88, we found that there was no easy way to implement
`Debug` for our `IterMut` and `Drain` iterators. Those are built on
`slice::IterMut` and `vec::Drain`, which implement `Debug` themselves,
but have no other way to access their data. With a new `as_slice()`
method, we can read the data and customize its presentation.
Clarify guarantees for `Box` allocation
This basically says `Box` does the obvious things for its allocations.
See also: https://users.rust-lang.org/t/alloc-crate-guarantees/24981
This may require a T-libs FCP? Not sure.
r? @sfackler
introduce benchmarks of BTreeSet.intersection
16 tests combining 4 kinds of contents with different sizes exposing edge cases.
The ones with asymmetric sizes are addressed by https://github.com/rust-lang/rust/pull/58577.
The pos_vs_neg cases seems (are were meant to be) the same as the neg_vs_pos case (same thing, reverse order) but reality shows a surprsing 25% difference.
fix overlapping references in BTree
This fixes two kinds of overlapping references in BTree (both found by running the BTree test suite in Miri).
In `into_slices_mut`, we did `k.into_key_slice_mut()` followed by `self.into_val_slice_mut()` (where `k` is a copy of `self`). Calling `into_val_slice_mut` calls `self.len()`, which creates a shared reference to `NodeHeader`, which unfortunately (due to padding) overlaps with the mutable reference returned by `into_key_slice_mut`. Hence the key slice got (partially) invalidated. The fix is to avoid creating an `&NodeHeader` after the first slice got created.
In the iterators, we used to first create the references that will be returned, and then perform the walk on the tree. Walking the tree creates references (such as `&mut InternalNode`) that overlap with all of the keys and values stored in a pointer; in particular, they overlap with the references the iterator will later return. This is fixed by reordering the operations of walking the tree and obtaining the inner references.
The test suite still passes (and it passes in Miri now!), but there is a lot of code here that I do not understand...
override `VecDeque::try_rfold`, also update iterator
This keeps the slice based iteration and updates the iterator state after each slice. It also uses a loop to reduce the amount of code.
This uses unsafe code, so some thorough review would be appreciated. Cc @RalfJung
This keeps the slice based iteration and updates the iterator
state after each slice. It also uses a loop to reduce the amount
of code.
This uses unsafe code, so some thorough review would be
appreciated.
There are two big categories of changes in here
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`)
- Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`)
I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.
split MaybeUninit into several features, expand docs a bit
This splits the `maybe_uninit` feature gate into several:
* `maybe_uninit` for what we will hopefully stabilize soon-ish.
* `maybe_uninit_ref` for creating references into `MaybeUninit`, for which the rules are not yet clear.
* `maybe_uninit_slice` for handling slices of `MaybeUninit`, which needs more API design work.
* `maybe_uninit_array` for creating arrays of `MaybeUninit` using a macro (because we don't have https://github.com/rust-lang/rust/issues/49147 yet).
Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use `get_ref` and `get_mut`.
I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.
fix Box::into_unique effecitvely transmuting to a raw ptr
Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type.
In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
Stabilize slice_sort_by_cached_key
I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639.
Signature: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key
```rust
impl [T] {
pub fn sort_by_cached_key<K, F>(&mut self, f: F)
where F: FnMut(&T) -> K, K: Ord;
}
```
That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?".
The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key
(I'm asking because it's exactly what I just needed the other day:
```rust
all_positions.sort_by_cached_key(|&n|
data::CITIES.iter()
.map(|x| *metric_closure.get_edge(n, x.pos).unwrap())
.sum::<usize>()
);
```
since caching that key is a pretty obviously good idea.)
Closes#34447
