| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Remove items that are unstable and deprecated
This removes unstable items that have been deprecated for more than one cycle.
- Since 1.16.0, `#![feature(enumset)]`
- All of `mod collections::enum_set`
- Since 1.15.0, `#![feature(borrow_state)]`
- `cell::BorrowState`
- `RefCell::borrow_state()`
- Since 1.15.0, `#![feature(is_unique)]`
- `Rc::is_unique()` (made private like `Arc::is_unique()`)
- Since 1.15.0, `#![feature(rc_would_unwrap)]`
- `Rc::would_wrap()`
- Since 1.13.0, `#![feature(binary_heap_extras)]`
- `BinaryHeap::push_pop()`
- `BinaryHeap::replace()`
- Since 1.12.0, `#![feature(as_unsafe_cell)]`
- `Cell::as_unsafe_cell()`
- `RefCell::as_unsafe_cell()`
- Since 1.12.0, `#![feature(map_entry_recover_keys)]`
- `btree_map::OccupiedEntry::remove_pair()`
- `hash_map::OccupiedEntry::remove_pair()`
- Since 1.11.0, `#![feature(float_extras)]`
- `Float::nan()`
- `Float::infinity()`
- `Float::neg_infinity()`
- `Float::neg_zero()`
- `Float::zero()`
- `Float::one()`
- `Float::integer_decode()`
- `f32::integer_decode()`
- `f32::ldexp()`
- `f32::frexp()`
- `f32::next_after()`
- `f64::integer_decode()`
- `f64::ldexp()`
- `f64::frexp()`
- `f64::next_after()`
- Since 1.11.0, `#![feature(zero_one)]`
- `num::Zero`
- `num::One`
|
|
|
|
[unstable, deprecated since 1.12.0]
|
|
* Changed btree_map's and hash_map's Entry (etc.) docs to be consistent
* Changed VecDeque's type and module summary sentences to be consistent
with each other as well as with other summary sentences in the module
* Changed HashMap's and HashSet's summary sentences to be less redundantly
phrased and also more consistant with the other summary sentences in the
module
* Also, added an example to Bound
|
|
* Added links where possible (limited because of facading)
* Changed references to methods from `foo()` to `foo` in module docs
* Changed references to methods from `HashMap::foo` to just `foo` in
top-level docs for `HashMap` and the `default` doc for `DefaultHasher`
* Various small other fixes
|
|
This greatly improves consistency.
|
|
* Store capacity_mask instead of capacity
* Move bucket index into RawBucket
* Bucket index is now always within [0..table_capacity)
* Clone RawTable using RawBucket
* Simplify iterators by moving logic into RawBuckets
* Make retain aware of the number of elements
|
|
This replaces the `std::collections::hash::table::RevMoveBuckets`
iterator with a simpler `while` loop. This iterator was only used for
dropping the remaining elements of a `RawTable`, so instead we can just
loop through directly and drop them in place.
This should be functionally equivalent to the former code, but a little
easier to read. I was hoping it might have some performance benefit
too, but it seems the optimizer was already good enough to see through
the iterator -- the generated code is nearly the same. Maybe it will
still help if an element type has more complicated drop code.
|
|
Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision
Noticed while reading docs just now.
It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed.
For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
|
|
more precise.
|
|
|
|
|
|
Exposes a boolean flag in RawTable and use it
instead of a bool field in HashMap.
Fixes: #40042
|
|
|
|
|
|
|
|
make doc consistent with var name
|
|
std: Add retain method for HashMap and HashSet
Fix #36648
r? @bluss
|
|
|
|
Reminding people of set terminology.
|
|
Fix #36648
|
|
Fix a few impl stability attributes
The versions show up in rustdoc.
|
|
|
|
The versions show up in rustdoc.
|
|
We should teach conversion from `str` to `String` using `to_string`
rather than the legacy `to_owned`.
|
|
CC #34761
|
|
Part of https://github.com/rust-lang/rust/issues/31869.
Also turn on the `missing_debug_implementations` lint at the crate
level.
|
|
Add docs for last undocumented `Default` `impl`.
Add doc comment for `Default` `impl` on `DefaultHasher`.
Fixes https://github.com/rust-lang/rust/issues/36265.
|
|
|
|
Smarter HashMap/HashSet pre-allocation for extend/from_iter
HashMap/HashSet from_iter and extend are making totally different assumptions.
A more balanced decision may allocate half the lower hint (rounding up). For "well defined" iterators this effectively limits the worst case to two resizes (the initial reserve + one resize).
cc #36579
cc @bluss
|
|
|
|
|
|
Don't reuse RandomState seeds
cc #36481
|
|
Remove unused type aliases
Found by extending the dead code lint. The lint itself is work in progress because of false positives.
cc #37455.
|
|
|
|
|
|
We can't use more than usize's bits of a hash to select a bucket anyway,
so we only need to store that part in the table. This should be an
improvement for the size of the data structure on 32-bit platforms.
Smaller data means better cache utilization and hopefully better
performance.
|
|
|
|
run rustfmt on libstd/collections/hash folder
|
|
std: Correct stability attributes for some implementations
These are displayed by rustdoc so should be correct.
|
|
std: Stabilize and deprecate APIs for 1.13
This commit is intended to be backported to the 1.13 branch, and works with the
following APIs:
Stabilized
* `i32::checked_abs`
* `i32::wrapping_abs`
* `i32::overflowing_abs`
* `RefCell::try_borrow`
* `RefCell::try_borrow_mut`
Deprecated
* `BinaryHeap::push_pop`
* `BinaryHeap::replace`
* `SipHash13`
* `SipHash24`
* `SipHasher` - use `DefaultHasher` instead in the `std::collections::hash_map`
module
Closes #28147
Closes #34767
Closes #35057
Closes #35070
|
|
This commit is intended to be backported to the 1.13 branch, and works with the
following APIs:
Stabilized
* `i32::checked_abs`
* `i32::wrapping_abs`
* `i32::overflowing_abs`
* `RefCell::try_borrow`
* `RefCell::try_borrow_mut`
* `DefaultHasher`
* `DefaultHasher::new`
* `DefaultHasher::default`
Deprecated
* `BinaryHeap::push_pop`
* `BinaryHeap::replace`
* `SipHash13`
* `SipHash24`
* `SipHasher` - use `DefaultHasher` instead in the `std::collections::hash_map`
module
Closes #28147
Closes #34767
Closes #35057
Closes #35070
|
|
Clarify HashMap's capacity handling.
HashMap has two notions of "capacity":
- "Usable capacity": the number of elements a hash map can hold without
resizing. This is the meaning of "capacity" used in HashMap's API,
e.g. the `with_capacity()` function.
- "Internal capacity": the number of allocated slots. Except for the
zero case, it is always larger than the usable capacity (because some
slots must be left empty) and is always a power of two.
HashMap's code is confusing because it does a poor job of
distinguishing these two meanings. I propose using two different terms
for these two concepts. Because "capacity" is already used in HashMap's
API to mean "usable capacity", I will use a different word for "internal
capacity". I propose "span", though I'm happy to consider other names.
|
|
|
|
These are displayed by rustdoc so should be correct.
|
|
Clean up hasher discussion on HashMap
* We never want to make guarantees about protecting against attacks.
* "True randomness" is not the right terminology to be using in this
context.
* There is significantly more nuance to the performance of SipHash than
"somewhat slow".
r? @steveklabnik
Follow up to discussion on #35371
|
|
|
|
This commit does the following.
- Changes the terminology for capacities used within HashMap's code.
"Internal capacity" is now consistently "raw capacity", and "usable
capacity" is now consistently just "capacity". This makes the code
easier to understand.
- Reworks capacity and raw capacity computations. Raw capacity
computations are now handled in a single place:
`DefaultResizePolicy::raw_capacity()`. This function correctly returns
zero when given zero, which means that the following cases now result
in a capacity of zero when they previously did not.
* `Hash{Map,Set}::with_capacity(0)`
* `Hash{Map,Set}::with_capacity_and_hasher(0)`
* `Hash{Map,Set}::shrink_to_fit()`, when used with a hash map/set whose
elements have all been removed
- Strengthens the language used in the comments describing the above
functions, to make it clearer when they will result in a map/set with
a capacity of zero. The new language is based on the language used for
the corresponding functions in `Vec`.
- Adds tests for the above zero-capacity cases.
- Removes `test_resize_policy` because it is no longer useful.
|