| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
|
|
|
|
This adds a couple of more diagnostic items to be used in Clippy.
I chose these particular ones because they were the types which we seem
to check for the most in Clippy. I'm not sure if the
`cfg_attr(not(test))` is needed, but it was also used for `Vec` and a
few other types.
|
|
Relax bounds on HashMap/HashSet
These APIs changed from the old bound listed to the new bound (possibly empty):
K: Hash + Eq -> K
* new
* with_capacity
K: Eq + Hash, S: BuildHasher -> K, S
* with_hasher
* with_capacity_and_hasher
* hasher
K: Eq + Hash + Debug -> K: Debug
S: BuildHasher -> S
HashMap as Debug
K: Eq + Hash -> K
S: BuildHasher + Default -> S: Default
HashMap as Default
Resolves #44777.
|
|
|
|
No functional changes are made, and all APIs are moved to strictly less
restrictive bounds.
These APIs changed from the old bound listed to the new bound:
T: Hash + Eq -> T
* new
* with_capacity
T: Eq + Hash, S: BuildHasher -> T
* with_hasher
* with_capacity_and_hasher
* hasher
T: Eq + Hash + Debug -> T: Debug
S: BuildHasher -> S
<HashSet as Debug>
T: Eq + Hash -> T
S: BuildHasher + Default -> S: Default
<HashSet as Default>
|
|
|
|
|
|
Consider this example: small_set = 0..2, large_set = 0..1000.
To efficiently compute the union of these sets, we should
* take all elements of the larger set
* for each element of the smaller set check it is not in the larger set
This is exactly what this commit does.
This particular optimization was implemented a year ago, but the
author mistaken `<` and `>`.
|
|
|
|
|
|
|
|
|
|
|
|
* `HashSet::get_or_insert`
* `HashSet::get_or_insert_with`
These provide a simplification of the `Entry` API for `HashSet`, with
names chosen to match the similar methods on `Option`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A few improvements to comments in user-facing crates
Not too many this time, and all concern comments (almost all doc comments) in user-facing crates (libstd, libcore, liballoc).
r? @steveklabnik
|
|
|
|
|
|
|
|
Relax some Hash bounds on HashMap<K, V, S> and HashSet<T, S>
Notably, hash iterators don't require any trait bounds to be iterated.
|
|
Use more impl header lifetime elision
Inspired by seeing explicit lifetimes on these two:
- https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html#impl-FusedIterator
- https://doc.rust-lang.org/nightly/std/primitive.u32.html#impl-Not
And a follow-up to https://github.com/rust-lang/rust/pull/54687, that started using IHLE in libcore.
Most of the changes in here fall into two big categories:
- Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop`, `Debug`, and `Clone`)
- 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](https://internals.rust-lang.org/t/impl-type-parameter-aliases/9403/2?u=scottmcm).
I also removed two lifetimes that turned out to be completely unused; see https://github.com/rust-lang/rust/issues/41960#issuecomment-464557423
|
|
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.
|
|
Notably, hash iterators don't require any trait bounds to be iterated.
|
|
|
|
|
|
|
|
Found with `git grep -P '\b([a-z]+)\s+\1\b'`
|
|
|
|
asymmetrically sized sets and extend unit tests slightly beyond that
|
|
|
|
|
|
|
|
|
|
Stabilize FusedIterator
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
Closes #35602
|
|
Also fix a spelling mistake.
|
|
|
|
FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).
The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.
|
|
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|