summary refs log tree commit diff
path: root/src/libstd/collections/hash
AgeCommit message (Collapse)AuthorLines
2018-04-19[beta] Tweak some stabilizations in libstdAlex Crichton-2/+2
This commit tweaks a few stable APIs in the `beta` branch before they hit stable. The `str::is_whitespace` and `str::is_alphanumeric` functions were deleted (added in #49381, issue at #49657). The `and_modify` APIs added in #44734 were altered to take a `FnOnce` closure rather than a `FnMut` closure. Closes #49581 Closes #49657
2018-04-02Use Alloc and Layout from core::heap.Mike Hommey-2/+4
94d1970bba87f2d2893f6e934e4c3f02ed50604d moved the alloc::allocator module to core::heap, moving e.g. Alloc and Layout out of the alloc crate. While alloc::heap reexports them, it's better to use them from where they really come from.
2018-03-28Rollup merge of #49400 - Diggsey:shrink-to, r=joshtriplettkennytm-0/+68
Implement `shrink_to` method on collections Fixes #49385
2018-03-27Implement `shrink_to` method on collectionsDiggory Blake-0/+68
2018-03-25Implement get_key_value for HashMap, BTreeMapDiggory Blake-0/+28
2018-03-15setting ABORTING_MALLOC for asmjs backendsnf-4/+0
2018-03-14try_reserve: disabling tests for asmjs, blocked by #48968snf-0/+4
2018-03-14implementing fallible allocation API (try_reserve) for Vec, String and HashMapsnf-29/+124
2018-03-06Rollup merge of #47463 - bluss:fused-iterator, r=alexcrichtonkennytm-14/+14
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
2018-03-05Remove a couple of `isize` references from hashmap docsTobias Bucher-29/+29
Also fix a spelling mistake.
2018-03-03core: Update stability attributes for FusedIteratorUlrik Sverdrup-14/+14
2018-03-03core: Stabilize FusedIteratorUlrik Sverdrup-14/+14
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.
2018-02-25Rollup merge of #48166 - ↵kennytm-2/+1
hedgehog1024:hedgehog1024-stabilize-entry_and_modify, r=alexcrichton Stabilize 'entry_and_modify' feature Stabilize `entry_and_modify` feature introduced by #44734. Closes #44733
2018-02-251.25.0 -> 1.26.-Manish Goregaokar-1/+1
2018-02-1338880 remove unnecessary self.table.size checkShaun Steenkamp-4/+0
2018-02-1338880 fix incorrect negationShaun Steenkamp-1/+1
2018-02-1338880 hashmap check size=0, not just capacity=0Shaun Steenkamp-30/+24
2018-02-1338880 restore original entry(key) methodShaun Steenkamp-1/+3
2018-02-12Stabilize 'entry_and_modify' feature for HashMaphedgehog1024-2/+1
2018-02-1238880 fixup add missing mutShaun Steenkamp-1/+1
2018-02-1238880 remove redundant extra functionShaun Steenkamp-14/+6
2018-02-0638880 use search_mut function rather than search_hashedShaun Steenkamp-3/+1
2018-02-0638880 don't compute hash when searching an empty HashMapShaun Steenkamp-5/+35
This addresses issue #38880
2018-01-28Document that `Index` ops can panic on `HashMap` & `BTreeMap`.Corey Farwell-2/+7
Fixes https://github.com/rust-lang/rust/issues/47011.
2018-01-24Auto merge of #47299 - cramertj:unsafe-placer, r=alexcrichtonbors-1/+1
Make core::ops::Place an unsafe trait Consumers of `Place` would reasonably expect that the `pointer` function returns a valid pointer to memory that can actually be written to.
2018-01-20Rename std::ptr::Shared to NonNullSimon Sapin-3/+3
`Shared` is now a deprecated `type` alias. CC https://github.com/rust-lang/rust/issues/27730#issuecomment-352800629
2018-01-09Make core::ops::Place an unsafe traitTaylor Cramer-1/+1
2018-01-07Add HashMap::remove_entrySteven Fackler-1/+49
Implements #46344
2018-01-05Write examples for {BTree,Hash}Set::{get,replace,take}Stjepan Glavina-0/+33
2017-12-13Remove Sync and Send implementation for RawTableKonrad Borowski-3/+0
The implementation was introduced when changing hash storage from Unique to *mut, but it was changed back to Unique.
2017-12-09Use Try syntax for Option in place of macros or matchMatt Brubeck-14/+6
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 14:56:04 +0000