about summary refs log tree commit diff
path: root/src/liballoc
AgeCommit message (Collapse)AuthorLines
2020-02-09Don't return empty slice on last iteration with matched terminator. Test ↵Pyry Kontio-9/+94
reverse iteration.
2020-02-09Implement split_inclusive for slice and str, an splitting iterator that ↵Pyry Kontio-0/+39
includes the matched part in the iterated substrings as a terminator.
2020-02-09Rollup merge of #68834 - ssomers:btree_first_last_fix68829, r=KodrAusDylan DPC-21/+35
Fix and test implementation of BTreeMap's first/last_entry, pop_first/last Properly implement and test `first_entry` & `last_entry` to fix problem report #68829
2020-02-08Refine and extend benchmarks of mutable BTreeSet methodsStein Somers-16/+85
2020-02-07Make rc::RcBox and sync::ArcInner repr(C)Lukas Lueg-0/+8
Future-proof these types in case rustc reorders the inner fields. As per discussion in PR #68099.
2020-02-07Auto merge of #68499 - ssomers:btree_search_tidying, r=Mark-Simulacrumbors-42/+101
BtreeMap range_search spruced up #39457 created a lower level entry point for `range_search` to operate on, but it's really not hard to move it up a level of abstraction, making it somewhat shorter and reusing existing unsafe code (`new_edge` is unsafe although it is currently not tagged as such). Benchmark added. Comparison says there's no real difference: ``` >cargo benchcmp old3.txt new3.txt --threshold 5 name old3.txt ns/iter new3.txt ns/iter diff ns/iter diff % speedup btree::map::find_seq_100 19 21 2 10.53% x 0.90 btree::map::range_excluded_unbounded 3,117 2,838 -279 -8.95% x 1.10 btree::map::range_included_unbounded 1,768 1,871 103 5.83% x 0.94 btree::set::intersection_10k_neg_vs_10k_pos 35 37 2 5.71% x 0.95 btree::set::intersection_staggered_100_vs_10k 2,488 2,314 -174 -6.99% x 1.08 btree::set::is_subset_10k_vs_100 3 2 -1 -33.33% x 1.50 ``` r? @Mark-Simulacrum
2020-02-07Lift range_search up one level of abstractionStein Somers-42/+45
2020-02-07Create benchmarks for BTreeMap::rangeStein Somers-0/+56
2020-02-06Rollup merge of #68524 - jonas-schievink:generator-resume-arguments, r=ZoxcDylan DPC-0/+24
Generator Resume Arguments cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974 Blockers: * [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069) * [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162) * [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901) * [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137) Follow-up work: * Change async/await desugaring to make use of this feature * Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
2020-02-04Fix and test implementation of BTreeMap's first_entry, last_entry, ↵Stein Somers-21/+35
pop_first, pop_last
2020-02-03Rollup merge of #68711 - hman523:fix-68593, r=Dylan-DPCDylan DPC-1/+4
Added upper bound of what vecs and boxes can allocate Fixed issue #68593 I added a line of documentation to these two files to reflect that vectors and boxes ensure that they never allocate more than `isize::MAX` bytes. r? @steveklabnik
2020-02-02Add a resume type parameter to `Generator`Jonas Schievink-0/+24
2020-02-01implement AsMut<str> for StringTrevor Spiteri-0/+8
2020-02-02Derive Clone + PartialEq + Eq for std::string::FromUtf8Errorkennytm-1/+5
2020-01-31Fixed issue 68593hman523-1/+4
2020-01-31Bundle and document 6 BTreeMap navigation algorithmsStein Somers-236/+314
2020-01-31Rollup merge of #68680 - ollie27:doc_alloc_playground, r=CentrilDylan DPC-0/+1
Add `#![doc(html_playground_url = ...)]` to alloc crate This adds the Run button to code examples just like the core and std docs have.
2020-01-30Add `#![doc(html_playground_url = ...)]` to alloc crateOliver Middleton-0/+1
This adds the Run button to code examples just like the core and std docs have.
2020-01-30Rollup merge of #68468 - ssomers:btreemap_prefer_middle, r=Mark-SimulacrumDylan DPC-119/+132
BTreeMap: tag and explain unsafe internal functions or assert preconditions #68418 concluded that it's not desirable to tag all internal functions with preconditions as being unsafe. This PR does it to some functions, documents why, and elsewhere enforces the preconditions with asserts.
2020-01-30Rollup merge of #66648 - crgl:btree-clone-from, r=AmanieuDylan DPC-9/+106
Implement clone_from for BTreeMap and BTreeSet See #28481. This results in up to 90% speedups on simple data types when `self` and `other` are the same size, and is generally comparable or faster. Some concerns: 1. This implementation requires an `Ord` bound on the `Clone` implementation for `BTreeMap` and `BTreeSet`. Since these structs can only be created externally for keys with `Ord` implemented, this should be fine? If not, there's certainly a less safe way to do this. 2. Changing `next_unchecked` on `RangeMut` to return mutable key references allows for replacing the entire overlapping portion of both maps without changing the external interface in any way. However, if `clone_from` fails it can leave the `BTreeMap` in an invalid state, which might be unacceptable. ~This probably needs an FCP since it changes a trait bound, but (as far as I know?) that change cannot break any external code.~
2020-01-29BTreeMap: tag and explain unsafe internal functions or assert preconditionsStein Somers-119/+132
Co-Authored-By: Mark Rousskov <mark.simulacrum@gmail.com>
2020-01-29Rollup merge of #68592 - pdbrito:master, r=jonas-schievinkYuki Okushi-1/+1
fix: typo in vec.rs
2020-01-29Rollup merge of #68378 - billyrieger:btreemap-remove-entry, r=KodrAusYuki Okushi-1/+30
Add BTreeMap::remove_entry Implements https://github.com/rust-lang/rust/issues/66714.
2020-01-28Refine [Arc/Rc]::from_raw() docsLukas Lueg-10/+26
2020-01-28Reformat truncation section of clone_fromCharles Gleason-10/+10
2020-01-28Add private is_empty method to RangeMutCharles Gleason-3/+7
2020-01-28Include empty BTreeMap in clone_from testsCharles Gleason-2/+2
2020-01-28Format safety comment as per tidyCharles Gleason-1/+1
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
2020-01-28Auto merge of #68529 - TimDiekmann:rename-alloc, r=Amanieubors-26/+26
Rename `Alloc` to `AllocRef` The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958. This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors. For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one. Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle. The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing. Blocked on https://github.com/rust-lang/miri/pull/1160
2020-01-28fix: typo in vec.rsPedro de Brito-1/+1
2020-01-28Add BTreeMap::remove_entryBilly Rieger-1/+30
Mainly for API parity with HashMap. - Add BTreeMap::remove_entry - Rewrite BTreeMap::remove to use remove_entry - Use btreemap_remove_entry feature in doc comment
2020-01-28Auto merge of #68234 - CAD97:slice-from-raw-parts, r=KodrAusbors-1/+0
Stabilize ptr::slice_from_raw_parts[_mut] Closes #36925, the tracking issue. Initial impl: #60667 r? @rust-lang/libs In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
2020-01-27Rename `Alloc` to `AllocRef`Tim Diekmann-26/+26
2020-01-21Rollup merge of #67686 - ssomers:keys_start_slasher, r=Mark-SimulacrumMazdak Farrokhzad-65/+24
Simplify NodeHeader by avoiding slices in BTreeMaps with shared roots Simplify a complicated piece of code that creates slices of keys in node leaves.
2020-01-21Declare unsafe functions that can no longer handle shared rootsStein Somers-6/+6
2020-01-21trade in outdated comments for correct onesStein Somers-2/+2
2020-01-21Auto merge of #68154 - ssomers:btreemap_navigation_benches, r=Mark-Simulacrumbors-8/+69
Add more BTreeMap/BTreeSet benchmarks regarding iteration Serving #67073 or other developments
2020-01-19FormatJonas Schievink-15/+14
2020-01-19Update comments in `Drain`s `Drop` implJonas Schievink-3/+5
2020-01-19Move VecDeque Drain iterator to new fileJonas Schievink-121/+131
2020-01-19Add test for panic in LL DrainFilter predicateJonas Schievink-0/+35
2020-01-19Avoid leak in DrainFilter when a drop panicsJonas Schievink-2/+50
2020-01-19Fix leak in vec::IntoIter when a destructor panicsJonas Schievink-1/+32
2020-01-19Fix leak in VecDeque::drain when drop panicsJonas Schievink-34/+86
2020-01-19Fix leak in btree_map::IntoIter when drop panicsJonas Schievink-1/+44
2020-01-19Avoid leak in `vec::Drain` when item drop panicsJonas Schievink-13/+69
2020-01-19Fix `VecDeque::truncate` leak on drop panicJonas Schievink-2/+50
2020-01-19Fix `binary_heap::DrainSorted` drop leak on panicsJonas Schievink-2/+47
2020-01-19Auto merge of #67758 - ssomers:testing_range, r=Mark-Simulacrumbors-31/+150
More thorough testing of BTreeMap::range Test more of the paths in the `range_search` function in map.rs
2020-01-17Allow added string.insert benchmarks to compileStein Somers-1/+1