summary refs log tree commit diff
path: root/src/libstd/collections
AgeCommit message (Collapse)AuthorLines
2017-11-11Improvided map_entry_replace examplesJeroen Bollen-12/+22
The current examples should be more realistic.
2017-11-11Changed tabs back into spaces to fix formatting.Jeroen Bollen-2/+2
2017-11-11Addressed issues raised in #44286.Jeroen Bollen-5/+27
This commit renames the `replace` function to `replace_entry`, and creates a seperate `replace_key` function for `OccupiedEntry`. The original `replace` function did not solve the use-case where the key needed to be replaced, but not the value. Documentation and naming has also been updated to better reflect what the original replace function does.
2017-11-08std: Remove `rand` crate and moduleAlex Crichton-4/+2
This commit removes the `rand` crate from the standard library facade as well as the `__rand` module in the standard library. Neither of these were used in any meaningful way in the standard library itself. The only need for randomness in libstd is to initialize the thread-local keys of a `HashMap`, and that unconditionally used `OsRng` defined in the standard library anyway. The cruft of the `rand` crate and the extra `rand` support in the standard library makes libstd slightly more difficult to port to new platforms, namely WebAssembly which doesn't have any randomness at all (without interfacing with JS). The purpose of this commit is to clarify and streamline randomness in libstd, focusing on how it's only required in one location, hashmap seeds. Note that the `rand` crate out of tree has almost always been a drop-in replacement for the `rand` crate in-tree, so any usage (accidental or purposeful) of the crate in-tree should switch to the `rand` crate on crates.io. This then also has the further benefit of avoiding duplication (mostly) between the two crates!
2017-10-20[test] Add some `#[inline]` to `HashMap`Alex Crichton-0/+3
2017-10-14std: Set probe length tag on cloned hashmapsManish Goregaokar-0/+1
This isn't strictly necessary for hashmap cloning to work. The tag is used to hint for an upcoming resize, so it's good to copy this information over. (We can do cleverer things like actually resizing the hashmap when we see the tag, or even cleaning up the entry order, but this requires more thought and might not be worth it)
2017-10-14std: Get rid of hash_offet in RawTableManish Goregaokar-16/+15
This offset is always zero, and we don't consistently take it into account. This is okay, because it's zero, but if it ever changes we're going to have bugs (e.g. in the `dealloc` call, where we don't take it into account). It's better to remove this for now; if we ever have a need for a nonzero offset we can add it back, and handle it properly when we do so.
2017-10-06Auto merge of #44734 - mchlrhw:wip/hashmap-entry-and-then, r=BurntSushibors-0/+35
Implement `and_modify` on `Entry` ## Motivation `Entry`s are useful for allowing access to existing values in a map while also allowing default values to be inserted for absent keys. The existing API is similar to that of `Option`, where `or` and `or_with` can be used if the option variant is `None`. The `Entry` API is, however, missing an equivalent of `Option`'s `and_then` method. If it were present it would be possible to modify an existing entry before calling `or_insert` without resorting to matching on the entry variant. Tracking issue: https://github.com/rust-lang/rust/issues/44733.
2017-10-06Implement `entry_and_modify`mchlrhw-0/+35
2017-10-05Auto merge of #44943 - nivkner:fixme_fixup, r=dtolnaybors-5/+5
address some FIXME whose associated issues were marked as closed part of #44366
2017-09-30address some `FIXME`s whose associated issues were marked as closedNiv Kaminer-5/+5
remove FIXME(#13101) since `assert_receiver_is_total_eq` stays. remove FIXME(#19649) now that stability markers render. remove FIXME(#13642) now the benchmarks were moved. remove FIXME(#6220) now that floating points can be formatted. remove FIXME(#18248) and write tests for `Rc<str>` and `Rc<[u8]>` remove reference to irelevent issues in FIXME(#1697, #2178...) update FIXME(#5516) to point to getopts issue 7 update FIXME(#7771) to point to RFC 628 update FIXME(#19839) to point to issue 26925
2017-09-29Rollup merge of #44794 - napen123:master, r=frewsxcvMark Simulacrum-0/+11
Add doc example to HashMap::hasher None
2017-09-28Auto merge of #44278 - Binero:master, r=BurntSushibors-0/+30
Allow replacing HashMap entries This is an obvious API hole. At the moment the only way to retrieve an entry from a `HashMap` is to get an entry to it, remove it, and then insert a new entry. This PR allows entries to be replaced.
2017-09-24Add doc example to HashMap::hasherEthan Dagner-0/+11
2017-09-15HashMap::new and HashSet::new do not allocateJon Gjengset-0/+6
2017-09-12Addressed @BurntSuchi's remarks regarding Entry::replaceJeroen Bollen-4/+3
2017-09-05Avoid weird or_insert_with exampleJon Gjengset-3/+1
2017-09-05Add or_default to Entry APIsJon Gjengset-0/+29
2017-09-03Marked `Entry::replace` as unstable.Jeroen Bollen-1/+2
2017-09-03Added a way to retrieve the key out of a HashMap when it's being replaced.Jeroen Bollen-0/+30
2017-08-15use field init shorthand EVERYWHEREZack M. Davis-18/+18
Like #43008 (f668999), but _much more aggressive_.
2017-08-10Auto merge of #43582 - ivanbakel:unused_mut_ref, r=arielb1bors-2/+2
Fixed mutable vars being marked used when they weren't #### NB : bootstrapping is slow on my machine, even with `keep-stage` - fixes for occurances in the current codebase are <s>in the pipeline</s> done. This PR is being put up for review of the fix of the issue. Fixes #43526, Fixes #30280, Fixes #25049 ### Issue Whenever the compiler detected a mutable deref being used mutably, it marked an associated value as being used mutably as well. In the case of derefencing local variables which were mutable references, this incorrectly marked the reference itself being used mutably, instead of its contents - with the consequence of making the following code emit no warnings ``` fn do_thing<T>(mut arg : &mut T) { ... // don't touch arg - just deref it to access the T } ``` ### Fix Make dereferences not be counted as a mutable use, but only when they're on borrows on local variables. #### Why not on things other than local variables? * Whenever you capture a variable in a closure, it gets turned into a hidden reference - when you use it in the closure, it gets dereferenced. If the closure uses the variable mutably, that is actually a mutable use of the thing being dereffed to, so it has to be counted. * If you deref a mutable `Box` to access the contents mutably, you are using the `Box` mutably - so it has to be counted.
2017-08-01Add doc example for HashSet::drain.Corey Farwell-0/+16
2017-08-01Remove unnecessary clones in doc examples.Corey Farwell-11/+11
2017-08-01Show the capacity in HashSet::with_capacity doc example.Corey Farwell-0/+1
2017-08-01Remove unnecessary 'mut' bindings.Corey Farwell-2/+2
2017-08-01Indicate HashSet is code-like in docs.Corey Farwell-1/+1
2017-08-01Show that the capacity changed in HashSet::reserve doc example.Corey Farwell-0/+1
2017-08-01Add doc example for HashSet::hasher.Corey Farwell-0/+11
2017-08-01Fixed extra cases found in better checking.Isaac van Bakel-1/+1
2017-08-01Fixed all unnecessary muts in language coreIsaac van Bakel-1/+1
2017-07-26Rollup merge of #42959 - SimonSapin:nonzero-checked, r=sfacklerMark Simulacrum-3/+3
Make the "main" constructors of NonZero/Shared/Unique return Option Per discussion in https://github.com/rust-lang/rust/issues/27730#issuecomment-303939441. This is a breaking change to unstable APIs. The old behavior is still available under the name `new_unchecked`. Note that only that one can be `const fn`, since `if` is currently not allowed in constant contexts. In the case of `NonZero` this requires adding a new `is_zero` method to the `Zeroable` trait. I mildly dislike this, but it’s not much worse than having a `Zeroable` trait in the first place. `Zeroable` and `NonZero` are both unstable, this can be reworked later.
2017-07-23Fix some doc/comment typos.Bruce Mitchener-1/+1
2017-07-22Add conversions from references to NonZero pointers, Unique, and SharedSimon Sapin-1/+1
2017-07-22Rename {NonZero,Shared,Unique}::new to new_uncheckedSimon Sapin-3/+3
2017-07-06Add annotations to the resize fn #39791Ryan Thomas-0/+2
This adds the `inline(never)` and `cold` annotations to the HashMap::resize function.
2017-07-05rustc: Implement the #[global_allocator] attributeAlex Crichton-6/+5
This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-30Revert "Stabilize RangeArgument"Steven Fackler-2/+0
This reverts commit 143206d54d7558c2326212df99efc98110904fdb.
2017-06-24Stabilize RangeArgumentSteven Fackler-0/+2
Move it and Bound to core::ops while we're at it. Closes #30877
2017-06-23Relax Debug constraints when debugging {HashMap,BTreeMap}::{Keys,Values}.Federico Ravasio-2/+2
Fixed #41924.
2017-06-21Impl Clone for DefaultHasherLeonardo Yvens-1/+1
2017-06-13Merge crate `collections` into `alloc`Murarth-6/+6
2017-05-21Auto merge of #41904 - sfackler:1.18-stabilization, r=alexcrichtonbors-34/+22
Stabilize library features for 1.18.0 Closes #38863 Closes #38980 Closes #38903 Closes #36648 r? @alexcrichton @rust-lang/libs
2017-05-20Stabilize library features for 1.18.0Steven Fackler-34/+22
Closes #38863 Closes #38980 Closes #38903 Closes #36648
2017-05-20migrate everything to using mem::needs_dropAlexis Beingessner-2/+1
2017-05-04Deprecate heap::EMPTY in favour of Unique::empty or otherwise.Alexis Beingessner-1/+2
2017-05-04fallout from NonZero/Unique/Shared changesAlexis Beingessner-9/+12
2017-04-23Auto merge of #41437 - cuviper:remove-unstable-deprecated, r=alexcrichtonbors-7/+0
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`
2017-04-22Fix invalid linkageGuillaume Gomez-2/+2
2017-04-20Remove OccupiedEntry::remove_pairJosh Stone-7/+0
[unstable, deprecated since 1.12.0]
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 13:31:49 +0000