about summary refs log tree commit diff
path: root/src/liballoc
AgeCommit message (Collapse)AuthorLines
2019-10-31Auto merge of #65091 - sekineh:into-iter-sorted, r=KodrAusbors-5/+204
Implement ordered/sorted iterators on BinaryHeap as per #59278 I've implemented the ordered version of iterator on BinaryHeap as per #59278. # Added methods: * `.into_iter_sorted()` * like `.into_iter()`; but returns elements in heap order * `.drain_sorted()` * like `.drain()`; but returns elements in heap order * It's a bit _lazy_; elements are removed on drop. (Edit: it’s similar to vec::Drain) For `DrainSorted` struct, I implemented `Drop` trait following @scottmcm 's [suggestion](https://github.com/rust-lang/rust/issues/59278#issuecomment-537306925) # ~TODO~ DONE * ~I think I need to add more tests other than doctest.~ # **Notes:** * we renamed `_ordered` to `_sorted`, because the latter is more common in rust libs. (as suggested by @KodrAus )
2019-10-28Rollup merge of #65887 - lzutao:doc-vec-get, r=rkruppeMazdak Farrokhzad-2/+4
doc: mention `get(_mut)` in Vec
2019-10-28doc: mention `get(_mut)` in VecLzu Tao-2/+4
2019-10-28Rollup merge of #65873 - lzutao:doc-vec-from-raw-parts, r=rkruppeMazdak Farrokhzad-1/+5
doc: explain why it is unsafe to construct Vec<u8> from Vec<u16>
2019-10-28Rollup merge of #64747 - ethanboxx:master, r=CentrilMazdak Farrokhzad-1/+0
Stabilize `Option::flatten` - PR: https://github.com/rust-lang/rust/pull/60256 - Tracking issue: https://github.com/rust-lang/rust/issues/60258 @elahn > I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it? @ethanboxx > @Centril Helped me get this merged. What is the stabilization process? @Centril > @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP. So here I am. I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
2019-10-27doc: explain why it is unsafe to construct Vec<u8> from Vec<u16>Lzu Tao-1/+5
Co-authored-by: Steve Klabnik <steve@steveklabnik.com>
2019-10-25Add {String,Vec}::into_raw_partsJake Goulding-0/+72
2019-10-25Use ManuallyDrop in examples for {Vec,String}::from_raw_partsJake Goulding-12/+14
2019-10-25Remove unneeded pointer castingJake Goulding-6/+6
2019-10-25fix doctestHideki Sekine-10/+4
2019-10-25Simplify .drain_sorted() and its doc.Hideki Sekine-45/+40
2019-10-25Remove unused `use`s.Hideki Sekine-4/+0
2019-10-25Add .into_iter_sorted() and .drain_sorted()Hideki Sekine-5/+219
* `.drain_sorted()` doc change suggested by @KodrAus
2019-10-23Rollup merge of #65144 - clarfon:moo, r=sfacklerMazdak Farrokhzad-0/+42
Add Cow::is_borrowed and Cow::is_owned Implements #65143.
2019-10-22Add Cow::is_borrowed and Cow::is_ownedClar Fon-0/+42
2019-10-22Apply clippy::needless_return suggestionsMateusz Mikuła-3/+3
2019-10-19Rollup merge of #65505 - RalfJung:rc, r=CentrilMazdak Farrokhzad-110/+137
Rc: value -> allocation See https://github.com/rust-lang/rust/issues/64484. This does not yet edit `Arc` as I first wanted to be sure we agree on the terminology the way it actually ends up. "value" as a term appears a lot in this file, and sometimes it refers to the value stored inside the `RcBox` while sometimes it refers to the `RcBox` itself. I tried to properly tease these apart but may have made some mistakes. The former should now always be called "inner value" and the latter "allocation". One area where I was very unsure of which terminology is dropping: the `value` field of the `RcBox` will get dropped *earlier* than the `RcBox` itself if there are weak references. I decided that "dropping the value stored in the allocation" refers to dropping the value field, while "destroying the allocation" refers to actually freeing its backing memory. r? @Centril
2019-10-19Rollup merge of #65226 - ssomers:master, r=blussMazdak Farrokhzad-121/+144
BTreeSet symmetric_difference & union optimized No scalability changes, but: - Grew the cmp_opt function (shared by symmetric_difference & union) into a MergeIter, with less memory overhead than the pairs of Peekable iterators now, speeding up ~20% on my machine (not so clear on Travis though, I actually switched it off there because it wasn't consistent about identical code). Mainly meant to improve readability by sharing code, though it does end up using more lines of code. Extending and reusing the MergeIter in btree_map might be better, but I'm not sure that's possible or desirable. This MergeIter probably pretends to be more generic than it is, yet doesn't declare to be an iterator because there's no need to, it's only there to help construct genuine iterators SymmetricDifference & Union. - Compact the code of #64820 by moving if/else into match guards. r? @bluss
2019-10-19do all the same edits with ArcRalf Jung-51/+65
2019-10-19some more Rc tweaksRalf Jung-10/+12
2019-10-19Stabilize `Option::flatten`Ethan Brierley-1/+0
2019-10-19the exampleis about drop, not (de)allocationRalf Jung-2/+2
2019-10-19Rollup merge of #65174 - SimonSapin:zero-box, r=alexcrichtonMazdak Farrokhzad-3/+33
Fix zero-size uninitialized boxes Requesting a zero-size allocation is not allowed, return a dangling pointer instead. CC https://github.com/rust-lang/rust/issues/63291#issuecomment-538692745
2019-10-18Uninitialized boxes: add test for zero-size allocationsSimon Sapin-0/+20
2019-10-18BTreeSet symmetric_difference & union optimized, cleanedStein Somers-121/+144
2019-10-17example for padding any formatRalf Jung-2/+6
2019-10-17reorder fmt docs for more clarityRalf Jung-42/+61
2019-10-17more consistency and clarificationRalf Jung-13/+17
2019-10-17Rc: value -> allocationRalf Jung-44/+51
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-9/+13
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-16Uninitialized boxes: check for zero-size allocation based on Layout::sizeSimon Sapin-4/+4
2019-10-14Rollup merge of #65332 - RalfJung:fmt, r=cramertjTyler Mandry-191/+175
std::fmt: reorder docs This moves the "Formatting Parameters" section up above right after the discussion of named and positional arguments. Then comes the "Syntax" section, summarizing the discussion of format string syntax. And only *then* we get to "Formatting Traits" -- that section has some *huge* code examples, so it really should not interrupt the discussion of the grammar. Also users are much more likely to come here to learn about the format string grammar than to come here to learn about the `Binary` trait.
2019-10-13Rollup merge of #65373 - kalabukdima:patch-1, r=jonas-schievinkMazdak Farrokhzad-2/+2
Fix typo in docs for `Rc` r? @czipperz
2019-10-13Rollup merge of #65214 - Amanieu:cfg_atomic, r=alexcrichtonMazdak Farrokhzad-1/+1
Split non-CAS atomic support off into target_has_atomic_load_store This PR implements my proposed changes in https://github.com/rust-lang/rust/issues/32976#issuecomment-518542029 by removing `target_has_atomic = "cas"` and splitting `target_has_atomic` into two separate `cfg`s: * `target_has_atomic = 8/16/32/64/128`: This indicates the largest width that the target can atomically CAS (which implies support for all atomic operations). * ` target_has_atomic_load_store = 8/16/32/64/128`: This indicates the largest width that the target can support loading or storing atomically (but may not support CAS). cc #32976 r? @alexcrichton
2019-10-13Fix typo in docs for `Rc`kalabukdima-2/+2
2019-10-13Rollup merge of #65069 - crgl:clone-from-vec-deque, r=blussMazdak Farrokhzad-2/+122
Implement Clone::clone_from for VecDeque See #28481. For simple data types with the target much longer than the source, this implementation can be significantly slower than the default (probably due to the use of truncate). However, it should be substantially faster when cloning from nested data structures with similar shapes or when cloning from VecDeques with similar lengths, hopefully more common use cases for clone_from.
2019-10-12remove confusing and redundant subsectionRalf Jung-17/+0
2019-10-12move Formatting Traits downRalf Jung-182/+182
2019-10-12std::fmt: move format string grammar to the bottomRalf Jung-24/+25
2019-10-11Auto merge of #64877 - lzutao:stabilize-repeat_generic_slice, r=SimonSapinbors-6/+1
Stabilize `slice::repeat` (feature `repeat_generic_slice`) Closes #48784 r? @SimonSapin
2019-10-10Override nth for VecDeque Iter and IterMutCharles Gleason-0/+20
2019-10-10Add tests for VecDeque clone_fromCharles Gleason-0/+23
2019-10-10Implement Clone::clone_from for VecDequeCharles Gleason-2/+79
2019-10-08Stabilize mem::take (mem_take)Jon Gjengset-1/+0
Tracking issue: https://github.com/rust-lang/rust/issues/61129
2019-10-08Split non-CAS atomic support off into target_has_atomic_load_storeAmanieu d'Antras-1/+1
2019-10-06Fix zero-size uninitialized boxesSimon Sapin-4/+14
Requesting a zero-size allocation is not allowed, return a dangling pointer instead. CC https://github.com/rust-lang/rust/issues/63291#issuecomment-538692745
2019-10-05Hide the `Iterator` specialization behind a traitJonas Schievink-5/+22
2019-10-05Deny specializing items not in the parent implJonas Schievink-0/+5
2019-10-03Rollup merge of #64975 - crgl:clone-from-linked-list, r=blussMazdak Farrokhzad-0/+56
Implement Clone::clone_from for LinkedList See #28481. This represents a substantial speedup when the list sizes are comparable, and shouldn't ever be significantly worse. Technically split_off is doing an unnecessary search, but the code is hopefully cleaner as a result. I'm happy to rework anything that needs to be changed as well!
2019-10-02Add test for LinkedList clone_fromCharles Gleason-0/+43
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-13 11:31:16 +0000