| 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.
|
|
|
|
|
|
Going along with or_insert_with, or_insert_with_key provides the
Entry's key to the lambda, avoiding the need to either clone the
key or the need to reimplement this body of this method from
scratch each time.
This is useful when the initial value for a map entry is derived
from the key. For example, the introductory Rust book has an
example Cacher struct that takes an expensive-to-compute lambda and
then can, given an argument to the lambda, produce either the
cached result or execute the lambda.
|
|
|
|
|
|
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>
|
|
No functional changes are made, and all APIs are moved to strictly less
restrictive bounds.
These APIs changed from the old bound listed to no trait bounds:
K: Hash + Eq
* new
* with_capacity
K: Eq + Hash, S: BuildHasher
* 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>
|
|
|
|
|
|
|
|
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 `>`.
|
|
Add lint and tests for unnecessary parens around types
This is my first contribution to the Rust project, so I apologize if I'm not doing things the right way.
The PR fixes #64169. It adds a lint and tests for unnecessary parentheses around types. I've run `tidy` and `rustfmt` — I'm not totally sure it worked right, though — and I've tried to follow the instructions linked in the readme.
I tried to think through all the variants of `ast::TyKind` to find exceptions to this lint, and I could only find the one mentioned in the original issue, which concerns types with `dyn`. I'm not a Rust expert, thought, so I may well be missing something.
There's also a problem with getting this to build. The new lint catches several things in the, e.g., `core`. Because `x.py` seems to build with an equivalent of `-Werror`, what would have been warnings cause the build to break. I got it to build and the tests to pass with `--warnings warn` on my `x.py build` and `x.py test` commands.
|
|
|
|
Added doc about behavior of extend on HashMap
It was unclear what the implementation does when it encounters existing keys. This change makes it clear by documenting the trait impl.
|
|
|
|
It was unclear what the implementation does when it encounters existing keys. This change makes it clear by documenting the trait impl.
|
|
|
|
|
|
… 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
|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/62301, a regression in 1.36.0 which was caused by hashbrown using `NonZero<T>` where the older hashmap used `Unique<T>`.
|
|
Fix intra-doc link resolution failure on re-exporting libstd
Currently, re-exporting libstd items as below will [occur a lot of failures](https://gist.github.com/taiki-e/e33e0e8631ef47f65a74a3b69f456366).
```rust
pub use std::*;
```
Until the underlying issue (#56922) fixed, we can fix that so they don't propagate to downstream crates.
Related: https://github.com/rust-lang/rust/pull/56941 (That PR fixed failures that occur when re-exporting from libcore to libstd.)
r? @QuietMisdreavus
|
|
doc: correct the origin of RawEntryMut
|
|
|
|
|
|
|
|
* `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
|
|
|
|
|