about summary refs log tree commit diff
path: root/library/alloc/src
AgeCommit message (Collapse)AuthorLines
2021-10-01Include the length in BTree hashesJosh Stone-0/+1
This change makes it consistent with `Hash` for all other collections.
2021-10-01Clarify a sentence in the documentation of Vec (#84488)chrismit3s-1/+1
2021-09-30Fix standard library for min_specialization changesMatthew Jasper-16/+13
2021-09-30fix issues pointed out in reviewThe8472-10/+11
2021-09-30implement advance_(back_)_by on more iteratorsThe8472-0/+46
2021-09-30Add truncate note to Vec::resizeOwen Gage-0/+1
2021-09-28Additional docs about Vec::leak behaviorMatt Brubeck-2/+5
2021-09-28Avoid allocations and copying in Vec::leakMatt Brubeck-1/+2
Don't shrink the Vec (by calling into_boxed_slice) before leaking it.
2021-09-26Auto merge of #89144 - sexxi-goose:insig_stdlib, r=nikomatsakisbors-0/+7
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-25Rollup merge of #89216 - r00ster91:bigo, r=dtolnayManish Goregaokar-7/+7
Consistent big O notation This makes the big O time complexity notation in places with markdown support more consistent. Inspired by #89210
2021-09-25Rollup merge of #89010 - est31:intra_doc_links, r=m-ou-seManish Goregaokar-9/+21
Add some intra doc links
2021-09-25Auto merge of #88343 - steffahn:fix_code_spacing, r=jyn514bors-70/+62
Fix spacing of links in inline code. Similar to #80733, but the focus is different. This PR eliminates all occurrences of pieced-together inline code blocks like [`Box`]`<`[`Option`]`<T>>` and replaces them with good-looking ones (using HTML-syntax), like <code>[Box]<[Option]\<T>></code>. As far as I can tell, I should’ve found all of these in the standard library (regex search with `` r"`\]`|`\[`" ``) \[except for in `core::convert` where I’ve noticed other things in the docs that I want to fix in a separate PR]. In particular, unlike #80733, I’ve added almost no new instance of inline code that’s broken up into multiple links (or some link and some link-free part). I also added tooltips (the stuff in quotes for the markdown link listings) in places that caught my eye, but that’s by no means systematic, just opportunistic. [Box]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [`Box`]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [Option]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" [`Option`]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" Context: I got annoyed by repeatedly running into new misformatted inline code while reading the standard library docs. I know that once issue #83997 (and/or related ones) are resolved, these changes become somewhat obsolete, but I fail to notice much progress on that end right now. r? `@jyn514`
2021-09-25Apply 16 commits (squashed)Frank Steffahn-70/+62
---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::fmt ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::{rc, sync} ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::string ---------- Fix spacing for links inside code blocks in alloc::vec ---------- Fix spacing for links inside code blocks in core::option ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in core::result ---------- Fix spacing for links inside code blocks in core::{iter::{self, iterator}, stream::stream, poll} ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{fs, path} ---------- Fix spacing for links inside code blocks in std::{collections, time} ---------- Fix spacing for links inside code blocks in and make formatting of `&str`-like types consistent in std::ffi::{c_str, os_str} ---------- Fix spacing for links inside code blocks, and improve link tooltips in std::ffi ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{io::{self, buffered::{bufreader, bufwriter}, cursor, util}, net::{self, addr}} ---------- Fix typo in link to `into` for `OsString` docs ---------- Remove tooltips that will probably become redundant in the future ---------- Apply suggestions from code review Replacing `…std/primitive.reference.html` paths with just `reference` Co-authored-by: Joshua Nelson <github@jyn.dev> ---------- Also replace `…std/primitive.reference.html` paths with just `reference` in `core::pin`
2021-09-25refactor: VecDeques PairSlices fields to privateDeveloperC-4/+4
2021-09-25Auto merge of #89030 - nbdd0121:box2, r=jonas-schievinkbors-1/+0
Introduce `Rvalue::ShallowInitBox` Polished version of #88700. Implements MCP rust-lang/compiler-team#460, and should allow #43596 to go forward. In short, creating an empty box is split from a nullary-op `NullOp::Box` into two steps, first a call to `exchange_malloc`, then a `Rvalue::ShallowInitBox` which transmutes `*mut u8` to a shallow-initialized `Box<T>`. This allows the `exchange_malloc` call to unwind. Details can be found in the MCP. `NullOp::Box` is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient. Experiments in #88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-`oom=panic` case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.
2021-09-25Use Rvalue::ShallowInitBox for box expressionGary Guo-1/+0
2021-09-24unitalicize O(1) complexitiesTakashi Idobe-4/+4
2021-09-24consistent big O notationr00ster91-7/+7
2021-09-23remove trailing whitespaceTakashi Idobe-4/+4
2021-09-23Add time complexities to linked_list.rsTakashi Idobe-0/+10
2021-09-22Rollup merge of #89036 - nbdd0121:alloc, r=yaahcthe8472-0/+3
Fix missing `no_global_oom_handling` cfg-gating Cfg-gate these trait impls that are neglected. These functions compile now because they use `box` syntax which depends on `exchange_malloc` during codegen only; as a result they compiles with cfg `no_global_oom_handling` but shouldn't. Discovered in #89030 because that PR makes `box` syntax depend on `exchange_malloc` lang item during MIR construction.
2021-09-22PR fixupAman Arora-7/+7
2021-09-212229: Annotate stdlib with insignficant dtorsAman Arora-0/+7
2021-09-17refactor: VecDeques IntoIter fields to privateDeveloperC286-2/+8
2021-09-17Fix missing `no_global_oom_handling` cfg-gatingGary Guo-0/+3
2021-09-17Optimize unnecessary check in Vec::retainTennyZhuang-3/+24
Co-authored-by: oxalica <oxalicc@pm.me>
2021-09-16Add IntoIterator intra doc link to various collectionsest31-5/+10
2021-09-16Add intra-doc-links to BinaryHeap rustdocest31-3/+7
2021-09-16Add intra-doc-links to LinkedList rustdocest31-1/+4
2021-09-15Const DerefDeadbeef-1/+5
2021-09-08Bump stage0 compiler to 1.56Mark Rousskov-3/+0
2021-09-08rearrange to be panic safetabokie-10/+12
Signed-off-by: tabokie <xy.tao@outlook.com>
2021-09-07Optimize VecDeque::appendtabokie-2/+28
Signed-off-by: tabokie <xy.tao@outlook.com>
2021-09-07Auto merge of #88448 - xu-cheng:btree-blk-build, r=Mark-Simulacrumbors-10/+101
BTreeMap/BTreeSet::from_iter: use bulk building to improve the performance Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one, we sort all the items beforehand then create the BtreeMap in bulk. Benchmark ``` ./x.py bench library/alloc --test-args btree::map::from_iter ``` * Before ``` test btree::map::from_iter_rand_100 ... bench: 3,694 ns/iter (+/- 840) test btree::map::from_iter_rand_10_000 ... bench: 1,033,446 ns/iter (+/- 192,950) test btree::map::from_iter_seq_100 ... bench: 5,689 ns/iter (+/- 1,259) test btree::map::from_iter_seq_10_000 ... bench: 861,033 ns/iter (+/- 118,815) ``` * After ``` test btree::map::from_iter_rand_100 ... bench: 3,033 ns/iter (+/- 707) test btree::map::from_iter_rand_10_000 ... bench: 775,958 ns/iter (+/- 105,152) test btree::map::from_iter_seq_100 ... bench: 2,969 ns/iter (+/- 336) test btree::map::from_iter_seq_10_000 ... bench: 258,292 ns/iter (+/- 29,364) ```
2021-09-05Fix typo: needede -> neededYechan Bae-1/+1
2021-09-05Rollup merge of #88432 - terrarier2111:patch-1, r=joshtriplettMara Bos-1/+1
Fix a typo in raw_vec
2021-09-02Rollup merge of #88505 - ibraheemdev:use-unwrap-unchecked, r=kennytmMara Bos-1/+4
Use `unwrap_unchecked` where possible
2021-09-01Rollup merge of #88040 - nbdd0121:btreemap, r=m-ou-seMara Bos-16/+20
BTree: remove Ord bound from new `K: Ord` bound is unnecessary on `BTree{Map,Set}::new` and their `Default` impl. No elements exist so there are nothing to compare anyway, so I don't think "future proof" would be a blocker here. This is analogous to `HashMap::new` not having a `K: Eq + Hash` bound. #79245 originally does this and for some reason drops the change to `new` and `Default`. I can see why changes to other methods like `entry` or `symmetric_difference` need to be careful but I couldn't find out any reason not to do it on `new`. Removing the bound also makes the stabilisation of `const fn new` not depending on const trait bounds. cc `@steffahn` who suggests me to make this PR. r? `@dtolnay`
2021-08-31add safety annotation to `LinkedList::detach_all_nodes`Ibraheem Ahmed-0/+3
Co-authored-by: kennytm <kennytm@gmail.com>
2021-08-30use `unwrap_unchecked` where possibleibraheemdev-1/+1
2021-08-28VecDeque: improve performance for From<[T; N]>Cheng XU-1/+41
Create VecDeque directly from the array instead of inserting items one-by-one.
2021-08-28BTreeSet::from_iter: use bulk building to improve the performanceCheng XU-5/+22
Apply the same optimization as BTreeMap::from_iter.
2021-08-28BTreeMap::from_iter: use bulk building to improve the performanceCheng XU-5/+79
Bulk building is a common technique to increase the performance of building a fresh btree map. Instead of inserting items one-by-one, we sort all the items beforehand then create the BtreeMap in bulk.
2021-08-28Fix a typo in raw_vecterrarier2111-1/+1
2021-08-26Add missing # Panics section to `Vec` methodSebastian Widua-1/+6
namely `Vec::extend_from_within`
2021-08-26Rollup merge of #88216 - kornelski:from_layout_err, r=kennytmManish Goregaokar-3/+3
Don't stabilize creation of TryReserveError instances #48043 + https://github.com/rust-lang/rust/pull/87993#issuecomment-903189016
2021-08-25Rollup merge of #88226 - steffahn:an_rc, r=michaelwoeristerLéo Lanteri Thauvin-1/+1
Fix typo “a Rc” → “an Rc” (and a few more) After stumbling about it in the dev-guide, I’ve devided to eliminate all mentions of “a Rc”, replacing it with “an Rc”. E.g. ```plain $ rg "(^|[^'])\ba\b[^\w=:]*\bRc" compiler/rustc_data_structures/src/owning_ref/mod.rs 1149:/// Typedef of a owning reference that uses a `Rc` as the owner. library/std/src/ffi/os_str.rs 919: /// Converts a [`OsString`] into a [`Rc`]`<OsStr>` without copying or allocating. library/std/src/ffi/c_str.rs 961: /// Converts a [`CString`] into a [`Rc`]`<CStr>` without copying or allocating. src/doc/rustc-dev-guide/src/query.md 61:are cheaply cloneable; insert a `Rc` if necessary). src/doc/book/src/ch15-06-reference-cycles.md 72:decreases the reference count of the `a` `Rc<List>` instance from 2 to 1 as library/alloc/src/rc.rs 1746: /// Converts a generic type `T` into a `Rc<T>` ``` _(the match in the book is a false positive)_ Since the dev-guide is a submodule, it’s getting a separate PR: rust-lang/rustc-dev-guide#1191 I’ve also gone ahead and done the same search for `RwLock` and hit a few cases in the `OwningRef` adaption. Then, I couldn’t keep the countless cases of “a owning …” or “a owner” unaddressed, which concludes this PR. `@rustbot` label C-cleanup
2021-08-25Rollup merge of #88156 - steffahn:arc_make_mut_and_weak, r=Mark-SimulacrumLéo Lanteri Thauvin-19/+39
Adjust / fix documentation of `Arc::make_mut` Related discussion in the users forum: [Whatʼs this alleged difference between Arc::make_mut and Rc::make_mut? – The Rust Programming Language Forum](https://users.rust-lang.org/t/what-s-this-alleged-difference-between-arc-make-mut-and-rc-make-mut/63747?u=steffahn) Also includes a small formatting improvement in the documentation of `Rc::make_mut`. This PR makes the two documentations in question complete analogs. The previously claimed point in which one “differs from the behavior of” the other turns out to be incorrect, AFAIK. One remaining inaccuracy: `Weak` pointers aren’t disassociated from the allocation but only from the contained value, i.e. in case of outstanding `Weak` pointers there still is a new allocation created, just the call to `.clone()` is avoided, instead the value is moved from one allocation to the other. `@rustbot` label T-libs-api, A-docs
2021-08-24Make explanations of cross-references between `make_mut` and `get_mut` more ↵Frank Steffahn-4/+6
accurate
2021-08-24Clarifiy weak pointers being diassociated…Frank Steffahn-4/+6
…noting the fact that `clone` is not called. Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 13:38:04 +0000