about summary refs log tree commit diff
path: root/library/alloc
AgeCommit message (Collapse)AuthorLines
2022-03-11Improve doc wording for retain on some collectionsMaik Allgöwer-6/+6
2022-03-10Rollup merge of #93950 - T-O-R-U-S:use-modern-formatting-for-format!-macros, ↵Dylan DPC-82/+82
r=Mark-Simulacrum Use modern formatting for format! macros This updates the standard library's documentation to use the new format_args 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). `eprintln!("{}", e)` becomes `eprintln!("{e}")`, but `eprintln!("{}", e.kind())` remains untouched.
2022-03-10Use implicit capture syntax in format_argsT-O-R-U-S-82/+82
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-03-10Revert accidental stabilizationOli Scherer-3/+2
2022-03-10Use MaybeUninit in VecDeque to remove the undefined behavior of sliceJmPotato-30/+95
Signed-off-by: JmPotato <ghzpotato@gmail.com>
2022-03-09BTreeMap::entry: Avoid allocating if no insertionFrank King-41/+86
2022-03-09Rollup merge of #94699 - ssomers:btree_prune_insert, r=Dylan-DPCDylan DPC-40/+19
BTree: remove dead data needlessly complicating insert Possibly needless instructions generated r? rust-lang/libs r? ``@Amanieu`` cc ``@frank-king``
2022-03-07Stabilize const_fn_fn_ptr_basics and const_fn_trait_boundEric Holk-1/+1
2022-03-07BTree: remove dead data needlessly complicating insertStein Somers-40/+19
2022-02-28Rollup merge of #92399 - Veeupup:fix_vec_typo, r=Dylan-DPCMatthias Krüger-4/+4
fix typo in btree/vec doc: Self -> self this pr fixes #92345 the documentation refers to the object the method is called for, not the type, so it should be using the lower case self.
2022-02-25Switch bootstrap cfgsMark Rousskov-1/+0
2022-02-25Rollup merge of #94184 - ssomers:btree_tests, r=Dylan-DPCMatthias Krüger-138/+118
BTree: simplify test code Mostly, use `from` & `from_iter`.
2022-02-22Auto merge of #83706 - a1phyr:fix_vec_layout_calculation, r=JohnTitorbors-5/+4
Fix a layout possible miscalculation in `alloc::RawVec` A layout miscalculation could happen in `RawVec` when used with a type whose size isn't a multiple of its alignment. I don't know if such type can exist in Rust, but the Layout API provides ways to manipulate such types. Anyway, it is better to calculate memory size in a consistent way.
2022-02-20BTree: simplify test codeStein Somers-138/+118
2022-02-19Fix some confusing wording and improve slice-search-related docsr00ster91-8/+20
2022-02-19Rollup merge of #92902 - ssomers:docter_drain, r=yaahcMatthias Krüger-25/+47
Improve the documentation of drain members hopefully fixes #92765
2022-02-19Collections: improve the documentation of drain membersStein Somers-25/+47
2022-02-18Rollup merge of #93613 - crlf0710:rename_to_async_iter, r=yaahcMatthias Krüger-4/+4
Move `{core,std}::stream::Stream` to `{core,std}::async_iter::AsyncIterator` Following amendments in https://github.com/rust-lang/rfcs/pull/3208/. cc #79024 cc ``@yoshuawuyts`` ``@joshtriplett``
2022-02-17Rollup merge of #89869 - kpreid:from-doc, r=yaahcMatthias Krüger-4/+13
Add documentation to more `From::from` implementations. For users looking at documentation through IDE popups, this gives them relevant information rather than the generic trait documentation wording “Performs the conversion”. For users reading the documentation for a specific type for any reason, this informs them when the conversion may allocate or copy significant memory versus when it is always a move or cheap copy. Notes on specific cases: * The new documentation for `From<T> for T` explains that it is not a conversion at all. * Also documented `impl<T, U> Into<U> for T where U: From<T>`, the other central blanket implementation of conversion. * The new documentation for construction of maps and sets from arrays of keys mentions the handling of duplicates. Future work could be to do this for *all* code paths that convert an iterable to a map or set. * I did not add documentation to conversions of a specific error type to a more general error type. * I did not add documentation to unstable code. This change was prepared by searching for the text "From<... for" and so may have missed some cases that for whatever reason did not match. I also looked for `Into` impls but did not find any worth documenting by the above criteria.
2022-02-14Describe VecDeque with more consistent namesStein Somers-110/+110
2022-02-13stabilize const_ptr_offsetSaltyKitkat-1/+0
2022-02-12Stabilise inherent_ascii_escape (FCP in #77174)ltdk-2/+1
2022-02-12Fix typoAlphyr-1/+1
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
2022-02-12Fix `shrink` and `capacity_from_bytes`Benoît du Garreau-2/+3
2022-02-12Fix a layout miscalculation in alloc::RawVecBenoît du Garreau-3/+1
2022-02-10Rollup merge of #93824 - Amanieu:stable_cfg_target_has_atomic, r=davidtwcoMatthias Krüger-1/+1
Stabilize cfg_target_has_atomic `target_has_atomic_equal_alignment` is now tracked separately in #93822. Closes #32976
2022-02-09Stabilize cfg_target_has_atomicAmanieu d'Antras-1/+1
Closes #32976
2022-02-09Fix typo in `std::fmt` docsTitus-1/+1
2022-02-08Allow comparing `Vec`s with different allocators using `==`Chayim Refael Friedman-1/+1
2022-02-07Add {floor,ceil}_char_boundary methods to strltdk-0/+93
2022-02-06Auto merge of #90414 - thomcc:count-chars-faster, r=nagisabors-0/+42
Optimize `core::str::Chars::count` I wrote this a while ago after seeing this function as a bottleneck in a profile, but never got around to contributing it. I saw it again, and so here it is. The implementation is fairly complex, but I tried to explain what's happening at both a high level (in the header comment for the file), and in line comments in the impl. Hopefully it's clear enough. This implementation (`case00_cur_libcore` in the benchmarks below) is somewhat consistently around 4x to 5x faster than the old implementation (`case01_old_libcore` in the benchmarks below), for a wide variety of workloads, without regressing performance on any of the workload sizes I've tried. I also improved the benchmarks for this code, so that they explicitly check text in different languages and of different sizes (err, the cross product of language x size). The results of the benchmarks are here: <details> <summary>Benchmark results</summary> <pre> test str::char_count::emoji_huge::case00_cur_libcore ... bench: 20,216 ns/iter (+/- 3,673) = 17931 MB/s test str::char_count::emoji_huge::case01_old_libcore ... bench: 108,851 ns/iter (+/- 12,777) = 3330 MB/s test str::char_count::emoji_huge::case02_iter_increment ... bench: 329,502 ns/iter (+/- 4,163) = 1100 MB/s test str::char_count::emoji_huge::case03_manual_char_len ... bench: 223,333 ns/iter (+/- 14,167) = 1623 MB/s test str::char_count::emoji_large::case00_cur_libcore ... bench: 293 ns/iter (+/- 6) = 19331 MB/s test str::char_count::emoji_large::case01_old_libcore ... bench: 1,681 ns/iter (+/- 28) = 3369 MB/s test str::char_count::emoji_large::case02_iter_increment ... bench: 5,166 ns/iter (+/- 85) = 1096 MB/s test str::char_count::emoji_large::case03_manual_char_len ... bench: 3,476 ns/iter (+/- 62) = 1629 MB/s test str::char_count::emoji_medium::case00_cur_libcore ... bench: 48 ns/iter (+/- 0) = 14750 MB/s test str::char_count::emoji_medium::case01_old_libcore ... bench: 217 ns/iter (+/- 4) = 3262 MB/s test str::char_count::emoji_medium::case02_iter_increment ... bench: 642 ns/iter (+/- 7) = 1102 MB/s test str::char_count::emoji_medium::case03_manual_char_len ... bench: 445 ns/iter (+/- 3) = 1591 MB/s test str::char_count::emoji_small::case00_cur_libcore ... bench: 18 ns/iter (+/- 0) = 3777 MB/s test str::char_count::emoji_small::case01_old_libcore ... bench: 23 ns/iter (+/- 0) = 2956 MB/s test str::char_count::emoji_small::case02_iter_increment ... bench: 66 ns/iter (+/- 2) = 1030 MB/s test str::char_count::emoji_small::case03_manual_char_len ... bench: 29 ns/iter (+/- 1) = 2344 MB/s test str::char_count::en_huge::case00_cur_libcore ... bench: 25,909 ns/iter (+/- 39,260) = 13299 MB/s test str::char_count::en_huge::case01_old_libcore ... bench: 102,887 ns/iter (+/- 3,257) = 3349 MB/s test str::char_count::en_huge::case02_iter_increment ... bench: 166,370 ns/iter (+/- 12,439) = 2071 MB/s test str::char_count::en_huge::case03_manual_char_len ... bench: 166,332 ns/iter (+/- 4,262) = 2071 MB/s test str::char_count::en_large::case00_cur_libcore ... bench: 281 ns/iter (+/- 6) = 19160 MB/s test str::char_count::en_large::case01_old_libcore ... bench: 1,598 ns/iter (+/- 19) = 3369 MB/s test str::char_count::en_large::case02_iter_increment ... bench: 2,598 ns/iter (+/- 167) = 2072 MB/s test str::char_count::en_large::case03_manual_char_len ... bench: 2,578 ns/iter (+/- 55) = 2088 MB/s test str::char_count::en_medium::case00_cur_libcore ... bench: 44 ns/iter (+/- 1) = 15295 MB/s test str::char_count::en_medium::case01_old_libcore ... bench: 201 ns/iter (+/- 51) = 3348 MB/s test str::char_count::en_medium::case02_iter_increment ... bench: 322 ns/iter (+/- 40) = 2090 MB/s test str::char_count::en_medium::case03_manual_char_len ... bench: 319 ns/iter (+/- 5) = 2109 MB/s test str::char_count::en_small::case00_cur_libcore ... bench: 15 ns/iter (+/- 0) = 2333 MB/s test str::char_count::en_small::case01_old_libcore ... bench: 14 ns/iter (+/- 0) = 2500 MB/s test str::char_count::en_small::case02_iter_increment ... bench: 30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::en_small::case03_manual_char_len ... bench: 30 ns/iter (+/- 1) = 1166 MB/s test str::char_count::ru_huge::case00_cur_libcore ... bench: 16,439 ns/iter (+/- 3,105) = 19777 MB/s test str::char_count::ru_huge::case01_old_libcore ... bench: 89,480 ns/iter (+/- 2,555) = 3633 MB/s test str::char_count::ru_huge::case02_iter_increment ... bench: 217,703 ns/iter (+/- 22,185) = 1493 MB/s test str::char_count::ru_huge::case03_manual_char_len ... bench: 157,330 ns/iter (+/- 19,188) = 2066 MB/s test str::char_count::ru_large::case00_cur_libcore ... bench: 243 ns/iter (+/- 6) = 20905 MB/s test str::char_count::ru_large::case01_old_libcore ... bench: 1,384 ns/iter (+/- 51) = 3670 MB/s test str::char_count::ru_large::case02_iter_increment ... bench: 3,381 ns/iter (+/- 543) = 1502 MB/s test str::char_count::ru_large::case03_manual_char_len ... bench: 2,423 ns/iter (+/- 429) = 2096 MB/s test str::char_count::ru_medium::case00_cur_libcore ... bench: 42 ns/iter (+/- 1) = 15119 MB/s test str::char_count::ru_medium::case01_old_libcore ... bench: 180 ns/iter (+/- 4) = 3527 MB/s test str::char_count::ru_medium::case02_iter_increment ... bench: 402 ns/iter (+/- 45) = 1579 MB/s test str::char_count::ru_medium::case03_manual_char_len ... bench: 280 ns/iter (+/- 29) = 2267 MB/s test str::char_count::ru_small::case00_cur_libcore ... bench: 12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case01_old_libcore ... bench: 12 ns/iter (+/- 0) = 2666 MB/s test str::char_count::ru_small::case02_iter_increment ... bench: 19 ns/iter (+/- 0) = 1684 MB/s test str::char_count::ru_small::case03_manual_char_len ... bench: 14 ns/iter (+/- 1) = 2285 MB/s test str::char_count::zh_huge::case00_cur_libcore ... bench: 15,053 ns/iter (+/- 2,640) = 20067 MB/s test str::char_count::zh_huge::case01_old_libcore ... bench: 82,622 ns/iter (+/- 3,602) = 3656 MB/s test str::char_count::zh_huge::case02_iter_increment ... bench: 230,456 ns/iter (+/- 7,246) = 1310 MB/s test str::char_count::zh_huge::case03_manual_char_len ... bench: 220,595 ns/iter (+/- 11,624) = 1369 MB/s test str::char_count::zh_large::case00_cur_libcore ... bench: 227 ns/iter (+/- 65) = 20792 MB/s test str::char_count::zh_large::case01_old_libcore ... bench: 1,136 ns/iter (+/- 144) = 4154 MB/s test str::char_count::zh_large::case02_iter_increment ... bench: 3,147 ns/iter (+/- 253) = 1499 MB/s test str::char_count::zh_large::case03_manual_char_len ... bench: 2,993 ns/iter (+/- 400) = 1577 MB/s test str::char_count::zh_medium::case00_cur_libcore ... bench: 36 ns/iter (+/- 5) = 16388 MB/s test str::char_count::zh_medium::case01_old_libcore ... bench: 142 ns/iter (+/- 18) = 4154 MB/s test str::char_count::zh_medium::case02_iter_increment ... bench: 379 ns/iter (+/- 37) = 1556 MB/s test str::char_count::zh_medium::case03_manual_char_len ... bench: 364 ns/iter (+/- 51) = 1620 MB/s test str::char_count::zh_small::case00_cur_libcore ... bench: 11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case01_old_libcore ... bench: 11 ns/iter (+/- 1) = 3000 MB/s test str::char_count::zh_small::case02_iter_increment ... bench: 20 ns/iter (+/- 3) = 1650 MB/s </pre> </details> I also added fairly thorough tests for different sizes and alignments. This completes on my machine in 0.02s, which is surprising given how thorough they are, but it seems to detect bugs in the implementation. (I haven't run the tests on a 32 bit machine yet since before I reworked the code a little though, so... hopefully I'm not about to embarrass myself). This uses similar SWAR-style techniques to the `is_ascii` impl I contributed in https://github.com/rust-lang/rust/pull/74066, so I'm going to request review from the same person who reviewed that one. That said am not particularly picky, and might not have the correct syntax for requesting a review from someone (so it goes). r? `@nagisa`
2022-02-05Mark __rgl_oom and __rd_oom as "C-unwind"Amanieu d'Antras-2/+3
2022-02-05Allow handle_alloc_error to unwindAmanieu d'Antras-2/+0
2022-02-05Ensure non-power-of-two sizes are tested in the Chars::count testThom Chiovoloni-2/+4
2022-02-05Optimize `core::str::Chars::count`Thom Chiovoloni-0/+40
2022-02-03Move `{core,std}::stream::Stream` to `{core,std}::async_iter::AsyncIterator`.Charles Lew-4/+4
2022-02-03Add tracking issue and impl for `Rc`.Richard Dodd-1/+36
2022-02-03impl `Arc::unwrap_or_clone`Richard Dodd-0/+35
The function gets the inner value, cloning only if necessary.
2022-01-30Rollup merge of #92887 - pietroalbini:pa-bootstrap-update, r=Mark-SimulacrumEric Huss-12/+8
Bootstrap compiler update r? ``@Mark-Simulacrum``
2022-01-28update cfg(bootstrap)sPietro Albini-12/+8
2022-01-26Rollup merge of #91861 - ↵Matthias Krüger-40/+35
juniorbassani:use-from-array-in-collections-examples, r=yaahc Replace iterator-based construction of collections by `Into<T>` Just a few quality of life improvements in the doc examples. I also removed some `Vec`s in favor of arrays.
2022-01-23Rollup merge of #90666 - bdbai:arc_new_cyclic, r=m-ou-seMatthias Krüger-27/+66
Stabilize arc_new_cyclic This stabilizes feature `arc_new_cyclic` as the implementation has been merged for one year and there is no unresolved questions. The FCP is not started yet. Closes #75861 . ``@rustbot`` label +T-libs-api
2022-01-22Update stabilization version of arc_new_cyclicMara Bos-2/+2
2022-01-21Rollup merge of #93109 - JakobDegen:arc-docs, r=m-ou-seMatthias Krüger-58/+42
Improve `Arc` and `Rc` documentation This makes two changes (I can split the PR if necessary, but the changes are pretty small): 1. A bunch of trait implementations claimed to be zero cost; however, they use the `Arc<T>: From<Box<T>>` impl which is definitely not free, especially for large dynamically sized `T`. 2. The code in deferred initialization examples unnecessarily used excessive amounts of `unsafe`. This has been reduced.
2022-01-20Remove unnecessary unsafe code in `Arc` deferred initialization examples.Jakob Degen-58/+42
2022-01-20Auto merge of #92138 - ↵bors-3/+9
AngelicosPhosphoros:try_smarter_vec_from_iter_48994_2, r=Mark-Simulacrum Improve capacity estimation in Vec::from_iter Iterates on the attempt made in #53086. Closes #48994
2022-01-19Improve estimation of capacity in Vec::from_iterAngelicosPhosphoros-3/+9
Closes #48994
2022-01-19Rollup merge of #89621 - digama0:patch-2, r=yaahcMatthias Krüger-1/+4
doc: guarantee call order for sort_by_cached_key `slice::sort_by_cached_key` takes a caching function `f: impl FnMut(&T) -> K`, which means that the order that calls to the caching function are made is user-visible. This adds a clause to the documentation to promise the current behavior, which is that `f` is called on all elements of the slice from left to right, unless the slice has len < 2 in which case `f` is not called. For example, this can be used to ensure that the following code is a correct way to involve the index of the element in the sort key: ```rust let mut index = 0; slice.sort_by_cached_key(|x| (my_key(index, x), index += 1).0); ```
2022-01-18Replace iterator-based construction of collections by `Into<T>`Júnior Bassani-40/+35
2022-01-18Rollup merge of #93016 - Amanieu:vec_spare_capacity, r=Mark-SimulacrumMatthias Krüger-4/+1
Stabilize vec_spare_capacity Closes #75017
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 16:10:15 +0000