about summary refs log tree commit diff
path: root/src/liballoc
AgeCommit message (Collapse)AuthorLines
2020-04-03Rollup merge of #69860 - faern:use-assoc-int-consts, r=dtolnayMazdak Farrokhzad-2/+2
Use associated numeric consts in documentation Now when the associated constants on int/float types are stabilized and the recommended way of accessing said constants (#68952). We can start using it in this repository, and recommend it via documentation example code. This PR is the reincarnation of #67913 minus the actual adding + stabilization of said constants. (EDIT: Now it's only changing the documentation. So users will see the new consts, but we don't yet update the internal code) Because of how fast bit rot happens to PRs that touch this many files, it does not try to replace 100% of the old usage of the constants in the entire repo, but a good chunk of them.
2020-04-03Fix link in task::Wake docsYoshua Wuyts-2/+4
2020-04-03Replace max/min_value() with MAX/MIN assoc constsLinus Färnstrand-2/+2
2020-04-02Auto merge of #70362 - TimDiekmann:alloc-overhaul, r=Amanieubors-474/+391
Overhaul of the `AllocRef` trait to match allocator-wg's latest consens; Take 2 GitHub won't let me reopen #69889 so I make a new PR. In addition to #69889 this fixes the unsoundness of `RawVec::into_box` when using allocators supporting overallocating. Also it uses `MemoryBlock` in `AllocRef` to unify `_in_place` methods by passing `&mut MemoryBlock`. Additionally, `RawVec` now checks for `size_of::<T>()` again and ignore every ZST. The internal capacity of `RawVec` isn't used by ZSTs anymore, as `into_box` now requires a length to be specified. r? @Amanieu fixes rust-lang/wg-allocators#38 fixes rust-lang/wg-allocators#41 fixes rust-lang/wg-allocators#44 fixes rust-lang/wg-allocators#51
2020-04-01Add missing allocation guard in `RawVec::grow`Tim Diekmann-0/+1
2020-04-01Rollup merge of #70632 - tspiteri:vec-new, r=sfacklerDylan DPC-0/+6
expand vec![] to Vec::new() The current expansion of `vec![]` calls `into_vec` on a boxed slice, which results in longer IR, and even after optimization, some unwinding artifacts are still present in the IR. This PR uses `Vec::new()` for `vec![]`. This also allows `vec![]` to be used in const expressions.
2020-04-01Rollup merge of #68770 - ssomers:btree_drain_filter, r=AmanieuDylan DPC-14/+671
BTreeMap/BTreeSet: implement drain_filter Provide an implementation of drain_filter for BTreeMap and BTreeSet. Should be optimal when the predicate picks only elements in leaf nodes with at least MIN_LEN remaining elements, which is a common case, at least when draining only a fraction of the map/set, and also when the predicate picks elements stored in internal nodes where the right subtree can easily let go of a replacement element. The first commit adds benchmarks with an external, naive implementation. to compare how much this claimed optimality-in-some-cases is actually worth.
2020-03-31expand vec![] to Vec::new()Trevor Spiteri-0/+6
2020-03-31Rollup merge of #69425 - lcnr:make_contiguous, r=AmanieuDylan DPC-53/+235
add fn make_contiguous to VecDeque Adds the following method to VecDeque: ```rust pub fn make_contiguous(&mut self) -> &mut [T]; ``` Taken from https://github.com/rust-lang/rust/pull/69400, after a suggestion by @CryZe https://github.com/rust-lang/rust/pull/69400#issuecomment-590216089 I am in favor of merging this instead of https://github.com/rust-lang/rust/pull/69400.
2020-03-31fix docsBastian Kauschke-1/+1
2020-03-31Rollup merge of #69784 - benesch:fast-strip-prefix-suffix, r=kennytmMazdak Farrokhzad-0/+15
Optimize strip_prefix and strip_suffix with str patterns As mentioned in https://github.com/rust-lang/rust/issues/67302#issuecomment-585639226. I'm not sure whether adding these methods to `Pattern` is desirable—but they have default implementations so the change is backwards compatible. Plus it seems like they're slated for wholesale replacement soon anyway? #56345 ---- Constructing a Searcher in strip_prefix and strip_suffix is unnecessarily slow when the pattern is a fixed-length string. Add strip_prefix and strip_suffix methods to the Pattern trait, and add optimized implementations of these methods in the str implementation. The old implementation is retained as the default for these methods.
2020-03-31update `VecDeque::as_(mut)_slice` docsBastian Kauschke-4/+4
2020-03-30Optimize strip_prefix and strip_suffix with str patternsNikhil Benesch-0/+15
Constructing a Searcher in strip_prefix and strip_suffix is unnecessarily slow when the pattern is a fixed-length string. Add strip_prefix and strip_suffix methods to the Pattern trait, and add optimized implementations of these methods in the str implementation. The old implementation is retained as the default for these methods.
2020-03-30fix BTreeMap test compilation with MiriRalf Jung-1/+1
2020-03-29BTreeMap/BTreeSet: implement and test drain_filterStein Somers-20/+653
2020-03-29Add benchmarks of drain_filter-like behaviourStein Somers-0/+24
2020-03-29Rollup merge of #70506 - ssomers:btreemap_testing_consts, r=RalfJungMazdak Farrokhzad-41/+49
BTreeMap testing: introduce symbolic constants and use height consistently Doesn't change what or how much is tested, except for some exact integer types, just for convenience and because `node::CAPACITY` is a usize. r? @RalfJung
2020-03-29Rollup merge of #68692 - jyn514:vec-from-array, r=LukasKalbertodtMazdak Farrokhzad-0/+16
impl From<[T; N]> for Vec<T> Closes https://github.com/rust-lang/rust/issues/67963
2020-03-29Implement `init` and `init_offset` on `AllocInit` and mark it unsafeTim Diekmann-4/+4
2020-03-28BTreeMap testing: introduce symbolic constants and refer to height consistently.Stein Somers-41/+49
2020-03-28Make fields in `MemoryBlock` publicTim Diekmann-28/+29
2020-03-26Remove alignment from `MemoryBlock`Tim Diekmann-89/+65
2020-03-26Fix safety section of `RawVec::into_box`Tim Diekmann-1/+2
2020-03-26Fix wording in `RawVec::from_raw_parts(_in)`Tim Diekmann-2/+2
2020-03-26Remove check for ZST in `RawVec::needs_to_grow`Tim Diekmann-2/+1
2020-03-26Refine docs for `RawVec::from_raw_parts(_in)`Tim Diekmann-4/+6
2020-03-26Remove the note on the internal capacity field in `RawVec`Tim Diekmann-3/+1
2020-03-26Fix assertion in `shrink` to use `capacity()` insteadTim Diekmann-1/+1
2020-03-26Fix comment in `RawVec::into_box()`Tim Diekmann-1/+1
2020-03-26Fix ZST handling for `RawVec`Tim Diekmann-6/+6
2020-03-26Fix issues from review and unsoundness of `RawVec::into_box`Tim Diekmann-210/+216
2020-03-26Overhaul of the `AllocRef` trait to match allocator-wg's latest consensTim Diekmann-414/+347
2020-03-26introduce `negative_impls` feature gate and documentNiko Matsakis-0/+1
They used to be covered by `optin_builtin_traits` but negative impls are now applicable to all traits, not just auto traits. This also adds docs in the unstable book for the current state of auto traits.
2020-03-24must_use on split_offKornel-2/+4
#70194
2020-03-23Apply suggestions from code reviewSaoirse Shipwreckt-5/+5
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
2020-03-23Update src/liballoc/task.rsSaoirse Shipwreckt-1/+1
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
2020-03-23More explicit; CFG on atomic pointerWithout Boats-3/+4
2020-03-23typoWithout Boats-1/+1
2020-03-23Improve safety implementation, fix typosWithout Boats-16/+12
2020-03-23Add Wake trait for safe construction of Wakers.Without Boats-0/+92
Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`: - We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`. Therefore, the Wake trait was left out of the initial version of the task waker API. However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait, which contains two methods - A required method `wake`, which is called by `Waker::wake` - A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From<Arc<W>> for RawWaker`.
2020-03-23Rollup merge of #70269 - matthiaskrgr:clippy_closures, r=Dylan-DPCMazdak Farrokhzad-2/+2
remove redundant closures (clippy::redundant_closure)
2020-03-22update `make_contiguous` docsBastian Kauschke-1/+3
Co-Authored-By: Amanieu d'Antras <amanieu@gmail.com>
2020-03-22Rollup merge of #70254 - matthiaskrgr:cl4ppy, r=CentrilDylan DPC-2/+1
couple more clippy fixes (let_and_return, if_same_then_else) * summarize if-else-code with identical blocks (clippy::if_same_then_else) * don't create variable bindings just to return the bound value immediately (clippy::let_and_return)
2020-03-22Rollup merge of #68099 - lukaslueg:into_raw_unsafe, r=LukasKalbertodtDylan DPC-10/+36
Amend Rc/Arc::from_raw() docs regarding unsafety [This](https://stackoverflow.com/questions/59671647/is-it-safe-to-clone-a-type-erased-arc-via-raw-pointer) question on SO boils down to "is it safe to `::from_raw()` a `Rc<T>`/`Arc<T>` using a dummy `T` even if `T` is never dereferenced via the new `Rc`/`Arc`?". It almost never is. This PR amends the docs of `from_raw()` regarding this point.
2020-03-22document invariant of `VecDeque::as_(mut)_slice`Bastian Kauschke-0/+6
2020-03-22remove redundant closures (clippy::redundant_closure)Matthias Krüger-2/+2
2020-03-22add `fn make_contiguous` to VecDequeBastian Kauschke-53/+227
2020-03-22don't create variable bindings just to return the bound value immediately ↵Matthias Krüger-2/+1
(clippy::let_and_return)
2020-03-21Rollup merge of #70194 - kornelski:must_split, r=joshtriplettMazdak Farrokhzad-0/+1
#[must_use] on split_off() I've noticed this function used for truncation in the wild. `must_use` will clear that up.
2020-03-21Rollup merge of #70111 - Mark-Simulacrum:btree-no-shared, r=cuviperMazdak Farrokhzad-246/+185
BTreeMap: remove shared root This replaces the shared root with `Option`s in the BTreeMap code, and then slightly cleans up the node manipulation code taking advantage of the removal of the shared root. I expect that further simplification is possible, but wanted to get this posted for initial review. Note that `BTreeMap::new()` continues to not allocate. Benchmarks seem within the margin of error/unaffected, as expected for an entirely predictable branch. ``` name alloc-bench-a ns/iter alloc-bench-b ns/iter diff ns/iter diff % speedup btree::map::iter_mut_20 20 21 1 5.00% x 0.95 btree::set::clone_100 1,360 1,439 79 5.81% x 0.95 btree::set::clone_100_and_into_iter 1,319 1,434 115 8.72% x 0.92 btree::set::clone_10k 143,515 150,991 7,476 5.21% x 0.95 btree::set::clone_10k_and_clear 142,792 152,916 10,124 7.09% x 0.93 btree::set::clone_10k_and_into_iter 146,019 154,561 8,542 5.85% x 0.94 ```
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 20:23:20 +0000