about summary refs log tree commit diff
path: root/library/std/src/collections/hash/map.rs
AgeCommit message (Collapse)AuthorLines
2023-02-05Fix typo in HashMap::with_capacityKiran Shila-1/+1
2022-11-06Added `const_hash` tracking issue idonestacked-3/+3
2022-11-06Made `Sip` const `Hasher`onestacked-3/+6
2022-10-29fix typo in hashmap and hashset try_reserve methodjoseLuís-1/+1
2022-10-02Make Hash{Set,Map}::with_hasher unstably constNixon Enraght-Moony-1/+2
2022-09-26remove cfg(bootstrap)Pietro Albini-2/+0
2022-08-22Move error trait into coreJane Losare-Lusby-0/+11
2022-06-23Rollup merge of #96173 - jmaargh:jmaargh/with-capacity-doc-fix, r=Dylan-DPCMichael Goulet-14/+21
Fix documentation for `with_capacity` and `reserve` families of methods Fixes #95614 Documentation for the following methods - `with_capacity` - `with_capacity_in` - `with_capacity_and_hasher` - `reserve` - `reserve_exact` - `try_reserve` - `try_reserve_exact` was inconsistent and often not entirely correct where they existed on the following types - `Vec` - `VecDeque` - `String` - `OsString` - `PathBuf` - `BinaryHeap` - `HashSet` - `HashMap` - `BufWriter` - `LineWriter` since the allocator is allowed to allocate more than the requested capacity in all such cases, and will frequently "allocate" much more in the case of zero-sized types (I also checked `BufReader`, but there the docs appear to be accurate as it appears to actually allocate the exact capacity). Some effort was made to make the documentation more consistent between types as well.
2022-06-20Fix typo in `HashMap::drain` docsnils-1/+1
It's a map, not a vector.
2022-06-19Fix documentation for with_capacity and reserve families of methodsjmaargh-14/+21
Documentation for the following methods with_capacity with_capacity_in with_capacity_and_hasher reserve reserve_exact try_reserve try_reserve_exact was inconsistent and often not entirely correct where they existed on the following types Vec VecDeque String OsString PathBuf BinaryHeap HashSet HashMap BufWriter LineWriter since the allocator is allowed to allocate more than the requested capacity in all such cases, and will frequently "allocate" much more in the case of zero-sized types (I also checked BufReader, but there the docs appear to be accurate as it appears to actually allocate the exact capacity). Some effort was made to make the documentation more consistent between types as well. Fix with_capacity* methods for Vec Fix *reserve* methods for Vec Fix docs for *reserve* methods of VecDeque Fix docs for String::with_capacity Fix docs for *reserve* methods of String Fix docs for OsString::with_capacity Fix docs for *reserve* methods on OsString Fix docs for with_capacity* methods on HashSet Fix docs for *reserve methods of HashSet Fix docs for with_capacity* methods of HashMap Fix docs for *reserve methods on HashMap Fix expect messages about OOM in doctests Fix docs for BinaryHeap::with_capacity Fix docs for *reserve* methods of BinaryHeap Fix typos Fix docs for with_capacity on BufWriter and LineWriter Fix consistent use of `hasher` between `HashMap` and `HashSet` Fix warning in doc test Add test for capacity of vec with ZST Fix doc test error
2022-06-15Add examples using `add_modify` to HashMapKarlWithK-2/+4
Updated the HashMap's documentation to include two references to add_modify. The first is when the `Entry` API is mentioned at the beginning. I was hesitant to change the "attack" example (although I believe that it is perfect example of where `add_modify` should be used) because both uses work equally, but one is more idiomatic (`add_modify`). The second is with the `entry` function that is used for the `Entry` API. The code example was a perfect use for `add_modify`, which is why it was changed to reflect that.
2022-06-13[perf] std: add missing `#[inline]` to `DefaultHasher::{new,default}`.Eduard-Mihai Burtescu-0/+2
2022-06-01Rollup merge of #94647 - Urgau:hash-map-many-mut, r=AmanieuYuki Okushi-0/+113
Expose `get_many_mut` and `get_many_unchecked_mut` to HashMap This pull-request expose the function [`get_many_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_mut) and [`get_many_unchecked_mut`](https://docs.rs/hashbrown/0.12.0/hashbrown/struct.HashMap.html#method.get_many_unchecked_mut) from `hashbrown` to the standard library `HashMap` type. They obviously keep the same API and are added under the (new) `map_many_mut` feature. - `get_many_mut`: Attempts to get mutable references to `N` values in the map at once. - `get_many_unchecked_mut`: Attempts to get mutable references to `N` values in the map at once, without validating that the values are unique.
2022-06-01Expose get_many_mut and get_many_unchecked_mut to HashMapLoïc BRANSTETT-0/+113
2022-05-23Put a bound on collection misbehaviorChristopher Durham-1/+2
As currently written, when a logic error occurs in a collection's trait parameters, this allows *completely arbitrary* misbehavior, so long as it does not cause undefined behavior in std. However, because the extent of misbehavior is not specified, it is allowed for *any* code in std to start misbehaving in arbitrary ways which are not formally UB; consider the theoretical example of a global which gets set on an observed logic error. Because the misbehavior is only bound by not resulting in UB from safe APIs and the crate-level encapsulation boundary of all of std, this makes writing user unsafe code that utilizes std theoretically impossible, as it now relies on undocumented QOI that unrelated parts of std cannot be caused to misbehave by a misuse of std::collections APIs. In practice, this is a nonconcern, because std has reasonable QOI and an implementation that takes advantage of this freedom is essentially a malicious implementation and only compliant by the most langauage-lawyer reading of the documentation. To close this hole, we just add a small clause to the existing logic error paragraph that ensures that any misbehavior is limited to the collection which observed the logic error, making it more plausible to prove the soundness of user unsafe code. This is not meant to be formal; a formal refinement would likely need to mention that values derived from the collection can also misbehave after a logic error is observed, as well as define what it means to "observe" a logic error in the first place. This fix errs on the side of informality in order to close the hole without complicating a normal reading which can assume a reasonable nonmalicious QOI. See also [discussion on IRLO][1]. [1]: https://internals.rust-lang.org/t/using-std-collections-and-unsafe-anything-can-happen/16640
2022-05-20Add complexity estimation of iterating over HashSet and HashMapAngelicosPhosphoros-0/+40
It is not obvious (at least for me) that complexity of iteration over hash tables depends on capacity and not length. Especially comparing with other containers like Vec or String. I think, this behaviour is worth mentioning. I run benchmark which tests iteration time for maps with length 50 and different capacities and get this results: ``` capacity - time 64 - 203.87 ns 256 - 351.78 ns 1024 - 607.87 ns 4096 - 965.82 ns 16384 - 3.1188 us ``` If you want to dig why it behaves such way, you can look current implementation in [hashbrown code](https://github.com/rust-lang/hashbrown/blob/f3a9f211d06f78c5beb81ac22ea08fdc269e068f/src/raw/mod.rs#L1933). Benchmarks code would be presented in PR related to this commit.
2022-05-09Use Rust 2021 prelude in std itself.Mara Bos-1/+1
2022-05-06Add a dedicated length-prefixing method to `Hasher`Scott McMurray-0/+8
This accomplishes two main goals: - Make it clear who is responsible for prefix-freedom, including how they should do it - Make it feasible for a `Hasher` that *doesn't* care about Hash-DoS resistance to get better performance by not hashing lengths This does not change rustc-hash, since that's in an external crate, but that could potentially use it in future.
2022-04-27HashMap doc: Don't use monospace font for 'Entry Api'Nixon Enraght-Moony-1/+1
2022-03-11Rollup merge of #94826 - allgoewer:fix-retain-documentation, r=yaahcDylan DPC-1/+1
Improve doc wording for retain on some collections I found the documentation wording on the various retain methods on many collections to be unusual. I tried to invert the relation by switching `such that` with `for which` .
2022-03-11Improve doc wording for retain on some collectionsMaik Allgöwer-1/+1
2022-03-10Use implicit capture syntax in format_argsT-O-R-U-S-9/+9
This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).
2022-02-25Switch bootstrap cfgsMark Rousskov-10/+10
2022-02-19Auto merge of #94148 - matthiaskrgr:rollup-jgea68f, r=matthiaskrgrbors-0/+4
Rollup of 7 pull requests Successful merges: - #92902 (Improve the documentation of drain members) - #93658 (Stabilize `#[cfg(panic = "...")]`) - #93954 (rustdoc-json: buffer output) - #93979 (Add debug assertions to validate NUL terminator in c strings) - #93990 (pre #89862 cleanup) - #94006 (Use a `Field` in `ConstraintCategory::ClosureUpvar`) - #94086 (Fix ScalarInt to char conversion) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2022-02-19Collections: improve the documentation of drain membersStein Somers-0/+4
2022-02-17Destabilise entry_insert5225225-2/+4
2022-02-01add a rustc::query_stability lintlcnr-0/+10
2022-01-01Rollup merge of #91593 - upsuper-forks:hashmap-set-methods-bound, r=dtolnayMatthias Krüger-77/+77
Remove unnecessary bounds for some Hash{Map,Set} methods This PR moves `HashMap::{into_keys,into_values,retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash, S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys,into_values}` on par with `HashMap::{keys,values,values_mut}` which are not bounded either.
2021-12-21Rollup merge of #90345 - passcod:entry-insert, r=dtolnayMatthias Krüger-6/+6
Stabilise entry_insert This stabilises `HashMap:Entry::insert_entry` etc. Tracking issue #65225. It will need an FCP. This was implemented in #64656 two years ago. This PR includes the rename and change discussed in https://github.com/rust-lang/rust/issues/65225#issuecomment-910652430, happy to split if needed.
2021-12-20Bump insert_entry stabilization to Rust 1.59David Tolnay-2/+2
2021-12-11Remove unnecessary bounds for some Hash{Map,Set} methodsXidorn Quan-77/+77
2021-12-10Rollup merge of #91482 - ↵Matthias Krüger-53/+70
JosephTLyons:update-HashMap-and-BTreeMap-documentation, r=yaahc Update documentation to use `from()` to initialize `HashMap`s and `BTreeMap`s As of Rust 1.56, `HashMap` and `BTreeMap` both have associated `from()` functions. I think using these in the documentation cleans things up a bit. It allows us to remove some of the `mut`s and avoids the Initialize-Then-Modify anti-pattern.
2021-12-04Use IntoIterator for array impl everywhere.Mara Bos-1/+1
2021-12-03Make `HashMap`s mutable againJoseph T Lyons-6/+6
2021-12-02Use `HashMap::from()` instead of using `HashMap::new()` with `HashMap::insert()`Joseph T Lyons-53/+70
2021-10-30Add #[must_use] to remaining std functions (A-N)John Kugelman-0/+5
2021-10-28Revert "Add rustc lint, warning when iterating over hashmaps"Mark Rousskov-10/+0
2021-10-28Stabilise entry_insertFélix Saparelli-4/+2
Signed-off-by: Félix Saparelli <felix@passcod.name>
2021-10-28Update doctests for renamesFélix Saparelli-2/+2
2021-10-28Expose HashMap:VacantEntry:insert_entryFélix Saparelli-1/+3
2021-10-28Rename HashMap:Entry:insert to :insert_entryFélix Saparelli-1/+1
2021-10-15add a `rustc::query_stability` lintlcnr-0/+10
2021-10-11Rollup merge of #89729 - jkugelman:must-use-core-std-constructors, ↵Guillaume Gomez-0/+4
r=joshtriplett Add #[must_use] to core and std constructors Parent issue: #89692 r? ``@joshtriplett``
2021-10-10Add #[must_use] to conversions that move selfJohn Kugelman-0/+3
2021-10-10Add #[must_use] to core and std constructorsJohn Kugelman-0/+4
2021-10-04Stabilize try_reserveKornel-2/+1
2021-10-02Make diangostic item names consistentCameron Steffen-1/+1
2021-09-26Auto merge of #89144 - sexxi-goose:insig_stdlib, r=nikomatsakisbors-0/+1
2229: Mark insignificant dtor in stdlib I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop. Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501 One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion. r? `@Mark-Simulacrum` cc `@nikomatsakis`
2021-09-22PR fixupAman Arora-0/+1
2021-09-16Add IntoIterator intra doc link to various collectionsest31-1/+2
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 18:36:28 +0000