| Age | Commit message (Collapse) | Author | Lines |
|---|
|
proposal for BTreeMap/Set min/max, #62924
- Which pair of names: #62924 lists the existing possibilities min/max, first/last, (EDIT) front/back, peek(/peek_back?). Iterators have next/next_back or next/last. I'm slightly in favour of first/last because min/max might suggest they search over the entire map, and front/back pretends they are only about position.
- Return key only instead of pair like iterator does?
- If not, then keep the _key_value suffix? ~~Also provide variant with mutable value? But there is no such variant for get_key_value.~~
- Look for and upgrade more usages of `.iter().next()` and such in the libraries? I only upgraded the ones I contributed myself, all very recently.
|
|
Use ptr::drop_in_place for VecDeque::truncate and VecDeque::clear
This commit allows `VecDeque::truncate` to take advantage of its (largely) contiguous memory layout and is consistent with the change in #64432 for `Vec`. As with the change to `Vec::truncate`, this changes both:
- the drop order, from back-to-front to front-to-back
- the behavior when dropping an element panics
For consistency, it also changes the behavior when dropping an element panics for `VecDeque::clear`.
These changes in behavior can be observed. This example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d0b1f2edc123437a2f704cbe8d93d828))
```rust
use std::collections::VecDeque;
fn main() {
struct Bomb(usize);
impl Drop for Bomb {
fn drop(&mut self) {
panic!(format!("{}", self.0));
}
}
let mut v = VecDeque::from(vec![Bomb(0), Bomb(1)]);
std::panic::catch_unwind(std::panic::AssertUnwindSafe(|| {
v.truncate(0);
}));
std::mem::forget(v);
}
```
panics printing `1` today and succeeds. `v.clear()` panics printing `0` today and succeeds. With the change, `v.clear()`, `v.truncate(0)`, and dropping the `VecDeque` all panic printing `0` first and then abort with a double-panic printing `1`.
The motivation for this was making `VecDeque::truncate` more efficient since it was used in the implementation of `VecDeque::clone_from` (#65069), but it also makes behavior more consistent within the `VecDeque` and with `Vec` if that change is accepted (this probably doesn't make sense to merge if not).
This might need a crater run and an FCP as well.
|
|
Fixed PhantomData markers in Arc and Rc
Include owned internal structs in `PhantomData` markers in `Arc` (`PhantomData<T>` => `PhantomData<ArcInner<T>>`) and `Rc` (`PhantomData<T>` => `PhantomData<RcBox<T>>`).
|
|
|
|
|
|
docs: improve disclaimer regarding LinkedList
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* `.drain_sorted()` doc change suggested by @KodrAus
|
|
|
|
|
|
BTreeSet symmetric_difference & union optimized
No scalability changes, but:
- Grew the cmp_opt function (shared by symmetric_difference & union) into a MergeIter, with less memory overhead than the pairs of Peekable iterators now, speeding up ~20% on my machine (not so clear on Travis though, I actually switched it off there because it wasn't consistent about identical code). Mainly meant to improve readability by sharing code, though it does end up using more lines of code. Extending and reusing the MergeIter in btree_map might be better, but I'm not sure that's possible or desirable. This MergeIter probably pretends to be more generic than it is, yet doesn't declare to be an iterator because there's no need to, it's only there to help construct genuine iterators SymmetricDifference & Union.
- Compact the code of #64820 by moving if/else into match guards.
r? @bluss
|
|
|
|
|
|
|
|
|
|
Implement Clone::clone_from for LinkedList
See #28481. This represents a substantial speedup when the list sizes are comparable, and shouldn't ever be significantly worse. Technically split_off is doing an unnecessary search, but the code is hopefully cleaner as a result. I'm happy to rework anything that needs to be changed as well!
|
|
|
|
|
|
|
|
Remove unneeded `fn main` blocks from docs
## [No whitespace diff](https://github.com/rust-lang/rust/pull/64912/files?w=1)
|
|
|
|
|
|
|
|
Improve BTreeSet::Intersection::size_hint
A comment on `IntersectionInner` mentions `small_iter` should be smaller than `other_iter` but this condition is broken while iterating because those two iterators can be consumed at a different rate. I added a test to demonstrate this situation.
<del>I made `small_iter.len() < other_iter.len()` always true by swapping two iterators when that condition became false. This change affects the return value of `size_hint`. The previous result was also correct but this new version always returns smaller upper bound than the previous version.</del>
I changed `size_hint` to taking minimum of both lengths of iterators and renamed fields to `a` and `b` to match `Union` iterator.
|
|
The commented invariant that an iterator is smaller than other iterator
was violated after next is called and two iterators are consumed at
different rates.
|
|
|
|
Constify LinkedList new function
Change the `LinkedList::new()` function to become a const fn, allowing the use in constant context.
|
|
|
|
|
|
Change the placement of two functions.
Right now, the order is as follows:
`pop_front()`
`push_front()`
`push_back()`
`pop_back()`
`swap_remove_back()`
`swap_remove_front()`
I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this:
`pop_front()`
`pop_back()`
`push_front()`
`push_back()`
`swap_remove_front()`
`swap_remove_back()`
The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.
|
|
|
|
… and add a separately-unstable field to force non-exhaustive matching
(`#[non_exhaustive]` is no implemented yet on enum variants)
so that we have the option to later expose the allocator’s error value.
CC https://github.com/rust-lang/wg-allocators/issues/23
|
|
|
|
Bump to 1.39
r? @Centril
|
|
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
|
|
Remove additional libcore-like restrictions from liballoc, turns out the testing works ok if the tests are a part of liballoc itself.
|
|
In which we constantly improve the Vec(Deque) array PartialEq impls
Use the same approach as in https://github.com/rust-lang/rust/pull/62435 as sanctioned by https://github.com/rust-lang/rust/issues/61415#issuecomment-504155110.
r? @scottmcm
|
|
Fix few Clippy warnings
|
|
|
|
Right now, the order is as follows:
`pop_front()`
`push_front()`
`push_back()`
`pop_back()`
`swap_remove_back()`
`swap_remove_front()`
I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this:
`pop_front()`
`pop_back()`
`push_front()`
`push_back()`
`swap_remove_front()`
`swap_remove_back()`
The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.
|
|
Rename .cap() methods to .capacity()
As mentioned in #60316, there are a few `.cap()` methods, which seem out-of-place because such methods are called `.capacity()` in the rest of the code.
This PR renames them to `.capacity()` but leaves `RawVec::cap()` in there for backwards compatibility.
I didn't try to mark the old version as "deprecated", because I guess this would cause too much noise.
|
