about summary refs log tree commit diff
path: root/library/std/src/collections
AgeCommit message (Collapse)AuthorLines
2021-01-31Add doc aliases for "delete"Konrad Borowski-0/+2
This patch adds doc aliases for "delete". The added aliases are supposed to reference usages `delete` in other programming languages. - `HashMap::remove`, `BTreeMap::remove` -> `Map#delete` and `delete` keyword in JavaScript. - `HashSet::remove`, `BTreeSet::remove` -> `Set#delete` in JavaScript. - `mem::drop` -> `delete` keyword in C++. - `fs::remove_file`, `fs::remove_dir`, `fs::remove_dir_all` -> `File#delete` in Java, `File#delete` and `Dir#delete` in Ruby. Before this change, searching for "delete" in documentation returned no results.
2021-01-30Replace predecessor with range in collections documentationKonrad Borowski-4/+4
Fixes #81548.
2021-01-26shrink_to shouldn't panic on len greater than capacityThom Wiggers-6/+2
2021-01-16Clarify what the effects of a 'logic error' areChris Jefferson-1/+6
2020-12-28Add "length" as doc alias to len methodsKonrad Borowski-0/+2
2020-12-26Use the hashbrown::{HashMap,HashSet} `clone_from` impls.David Adler-2/+35
2020-12-19Rollup merge of #78083 - ChaiTRex:master, r=m-ou-seYuki Okushi-5/+7
Stabilize or_insert_with_key Stabilizes the `or_insert_with_key` feature from https://github.com/rust-lang/rust/issues/71024. This allows inserting key-derived values when a `HashMap`/`BTreeMap` entry is vacant. The difference between this and `.or_insert_with(|| ... )` is that this provides a reference to the key to the closure after it is moved with `.entry(key_being_moved)`, avoiding the need to copy or clone the key.
2020-12-07Improved documentation for HashMap/BTreeMap Entry's .or_insert_with_key methodChai T. Rex-3/+6
2020-12-01Update rustc version that or_insert_with_key landedChai T. Rex-1/+1
2020-11-13Rollup merge of #77996 - tkaitchuck:master, r=m-ou-seGuillaume Gomez-3/+3
Doc change: Remove mention of `fnv` in HashMap Disclaimer: I am the author of [aHash](https://github.com/tkaitchuck/aHash). This changes the Rustdoc in `HashMap` from mentioning the `fnv` crate to mentioning the `aHash` crate, as an alternative `Hasher` implementation. ### Why Fnv [has poor hash quality](https://github.com/rurban/smhasher), is [slow for larger keys](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), and does not provide dos resistance, because it is unkeyed (this can also cause [other problems](https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion)). Fnv has acceptable performance for integers and has very poor performance with keys >32 bytes. This is the reason it was removed from the standard library in https://github.com/rust-lang/rust/pull/37229 . Because regardless of which dimension you value, there are better alternatives, it does not make sense for anyone to consider using `fnv`. The text mentioning `fnv` in the standard library continues to create confusion: https://github.com/rust-lang/hashbrown/issues/153 https://github.com/rust-lang/hashbrown/issues/9 . There are also a number of [crates using it](https://crates.io/crates/fnv/reverse_dependencies) a great many of which are hashing strings (Which is when Fnv is the [worst](https://github.com/cbreeden/fxhash#benchmarks), [possible](https://github.com/tkaitchuck/aHash#speed), [choice](http://cglab.ca/~abeinges/blah/hash-rs/).) I think aHash makes the most sense to mention as an alternative because it is the most credible option (in my obviously biased opinion). It offers [good performance on numbers and strings](https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md#speed), is [of high quality](https://github.com/tkaitchuck/aHash#hash-quality), and [provides dos resistance](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks). It is popular (see [stats](https://crates.io/crates/ahash)) and is the default hasher for [hashbrown](https://crates.io/crates/hashbrown) and [dashmap](https://crates.io/crates/dashmap) which are the most popular alternative hashmaps. Finally it does not have any of the [`gotcha` cases](https://github.com/tkaitchuck/aHash#fxhash) that `FxHash` suffers from. (Which is the other popular hashing option when DOS attacks are not a concern) Signed-off-by: Tom Kaitchuck <tom.kaitchuck@emc.com>
2020-11-12Update library/std/src/collections/hash/map.rsTom Kaitchuck-1/+1
Co-authored-by: Mara Bos <m-ou.se@m-ou.se>
2020-11-07Convert a bunch of intra-doc linksCamelid-4/+0
2020-10-27Change link to point to crates.io keyword "hasher"Tom Kaitchuck-3/+3
Signed-off-by: Tom Kaitchuck <Tom.Kaitchuck@gmail.com>
2020-10-26Improve formatting of hash collections docsCamelid-5/+6
2020-10-18Stabilize or_insert_with_keyChai T. Rex-2/+1
2020-10-15Change mention of `fnv` in HashMap to mention `aHash` as an alternitive hasher.Tom Kaitchuck-2/+2
Signed-off-by: Tom Kaitchuck <tom.kaitchuck@emc.com>
2020-10-04Rollup merge of #77072 - sharnoff:hash-docs, r=LukasKalbertodtJonas Schievink-20/+20
Minor `hash_map` doc adjustments + item attribute orderings This PR is really a couple visual changes glued together: 1. Some of the doc comments for items in `std::collections::hash_map` referenced the names of types without escaping their formatting (e.g. using "VacantEntry" instead of "`VacantEntry`") - the ones I could find were changed to the latter 2. The vast majority of pre-item attributes seem to place doc comments as the first attribute (instead of things like `#[feature(...)]`), so the few that had the other order were changed. 3. Also ordering related: the general trend seems to be that `#[feature]` attributes follow `#[inline]`, so I swapped the two lines in places where that ordering was reversed. This is primarily a change based on stylistic continuity and aesthetics - I'm not sure how important that actually is / should be. I figured this would be pretty uncontroversial, but some of these might have been intentional for reasons I don't know about - if so, I'd be happy to remove the relevant changes. Of these, the final set of changes is probably the most unnecessary, so it also might be better to leave those out (in favor of reducing code churn).
2020-10-03Rollup merge of #75377 - canova:map_debug_impl, r=dtolnayJonas Schievink-8/+4
Fix Debug implementations of some of the HashMap and BTreeMap iterator types HashMap's `ValuesMut`, BTreeMaps `ValuesMut`, IntoValues and `IntoKeys` structs were printing both keys and values on their Debug implementations. But they are iterators over either keys or values. Irrelevant values should not be visible. With this PR, they only show relevant fields. This fixes #75297. [Here's an example code.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0c79356ed860e347a0c1a205616f93b7) This prints this on nightly: ``` ValuesMut { inner: IterMut { range: [(1, "hello"), (2, "goodbye")], length: 2 } } IntoKeys { inner: [(1, "hello"), (2, "goodbye")] } IntoValues { inner: [(1, "hello"), (2, "goodbye")] } [(2, "goodbye"), (1, "hello")] ``` After the patch this example prints these instead: ``` ["hello", "goodbye"] ["hello", "goodbye"] [1, 2] ["hello", "goodbye"] ``` I didn't add test cases for them, since I couldn't see any tests for Debug implementations anywhere. But please let me know if I should add it to a specific place. r? @dtolnay
2020-10-02Link `new` method in `DefautHasher`s docWaffle-4/+3
2020-09-27Rollup merge of #76917 - GuillaumeGomez:map-missing-code-examples, r=Dylan-DPCJonas Schievink-1/+106
Add missing code examples on HashMap types r? @Dylan-DPC
2020-09-22minor doc changes, attribute orderingssharnoff-20/+20
2020-09-21Add missing code examples on HashMap typesGuillaume Gomez-1/+106
2020-09-20Rollup merge of #76887 - GuillaumeGomez:hashset-iter-types-examples, r=Dylan-DPCRalf Jung-0/+86
Add missing examples on HashSet iter types
2020-09-18Add missing examples on HashSet iter typesGuillaume Gomez-0/+86
2020-09-18Fixed intra-docs links in library/std/src/collections/hash/map.rsAmjad Alsharafi-6/+0
2020-09-08Tests for HashMap/HashSet::drain_filterMatt Brubeck-0/+232
2020-09-08Add HashMap::drain_filter and HashSet::drain_filterMatt Brubeck-0/+171
Implements #59618.
2020-09-08Implement HashSet in terms of hashbrown::HashSetMatt Brubeck-58/+53
2020-09-08Update to hashbrown 0.9Matt Brubeck-5/+5
2020-09-06Auto merge of #76128 - poliorcetics:doc-use-arc-clone, r=KodrAusbors-2/+2
Use Arc::clone and Rc::clone in documentation This PR replaces uses of `x.clone()` by `Rc::clone(&x)` (or `Arc::clone(&x)`) to better match the documentation for those types. @rustbot modify labels: T-doc
2020-08-31std: move "mod tests/benches" to separate filesLzu Tao-1350/+1346
Also doing fmt inplace as requested.
2020-08-30Move to Arc::clone(&x) over x.clone() in library/stdAlexis Bourget-2/+2
2020-08-23Switch to intra-doc links in `std::collections`Camelid-9/+1
2020-08-11Remove the unused bounds from Debug impl of HashMap::{IntoKeys,IntoValues}Nazım Can Altınova-2/+2
2020-08-10Only print values in the Debug of HashMap::ValuesMut structNazım Can Altınova-6/+2
2020-08-08Update the tracking issue number of map_into_keys_valuesNazım Can Altınova-12/+12
2020-08-07Only print the fields that are relevant to iterators for Debug of IntoKeys ↵Nazım Can Altınova-2/+2
and IntoValues
2020-08-07Add unit tests for new `HashMap::into_{keys,values}` methodsNazım Can Altınova-0/+24
2020-08-07Add `into_{keys,values}` methods for HashMapNazım Can Altınova-0/+128
2020-08-07Update hashbrown to 0.8.1Amanieu d'Antras-4/+4
2020-07-27mv std libs to library/mark-0/+5984
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 00:20:15 +0000