| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Stabilize library features for 1.18.0
Closes #38863
Closes #38980
Closes #38903
Closes #36648
r? @alexcrichton
@rust-lang/libs
|
|
Closes #38863
Closes #38980
Closes #38903
Closes #36648
|
|
|
|
|
|
|
|
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
|
|
|
|
Fixes #39661
Clarifies the potential ambiguity.
|
|
Reminding people of set terminology.
|
|
|
|
Clarified potential ambiguity.
|
|
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.
|
|
hashmap: Store hashes as usize internally
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.
Fixes #36567
|
|
|
|
|
|
|
|
This is overdue, even if range and RangeArgument is still unstable.
The stability attributes are the same ones as the other unstable item
(Bound) here, they don't seem to matter.
|
|
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.
|