about summary refs log tree commit diff
path: root/src/liballoc/boxed.rs
AgeCommit message (Collapse)AuthorLines
2019-07-04Rollup merge of #62316 - khuey:efficient_last, r=sfacklerMazdak Farrokhzad-0/+8
When possible without changing semantics, implement Iterator::last in terms of DoubleEndedIterator::next_back for types in liballoc and libcore. Provided that the iterator has finite length and does not trigger user-provided code, this is safe. What follows is a full list of the DoubleEndedIterators in liballoc/libcore and whether this optimization is safe, and if not, why not. src/liballoc/boxed.rs Box: Pass through to avoid defeating optimization of the underlying DoubleIterator implementation. This has no correctness impact. src/liballoc/collections/binary_heap.rs Iter: Pass through to avoid defeating optimizations on slice::Iter IntoIter: Not safe, changes Drop order Drain: Not safe, changes Drop order src/liballoc/collections/btree/map.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order Keys: Safe to call next_back, invokes no user defined code. Values: ditto ValuesMut: ditto Range: ditto RangeMut: ditto src/liballoc/collections/btree/set.rs Iter: Safe to call next_back, invokes no user defined code. IntoIter: Not safe, changes Drop order Range: Safe to call next_back, invokes no user defined code. src/liballoc/collections/linked_list.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order src/liballoc/collections/vec_deque.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order Drain: ditto src/liballoc/string.rs Drain: Safe because return type is a primitive (char) src/liballoc/vec.rs IntoIter: Not safe, changes Drop order Drain: ditto Splice: ditto src/libcore/ascii.rs EscapeDefault: Safe because return type is a primitive (u8) src/libcore/iter/adapters/chain.rs Chain: Not safe, invokes user defined code (Iterator impl) src/libcore/iter/adapters/flatten.rs FlatMap: Not safe, invokes user defined code (Iterator impl) Flatten: ditto FlattenCompat: ditto src/libcore/iter/adapters/mod.rs Rev: Not safe, invokes user defined code (Iterator impl) Copied: ditto Cloned: Not safe, invokes user defined code (Iterator impl and T::clone) Map: Not safe, invokes user defined code (Iterator impl + closure) Filter: ditto FilterMap: ditto Enumerate: Not safe, invokes user defined code (Iterator impl) Skip: ditto Fuse: ditto Inspect: ditto src/libcore/iter/adapters/zip.rs Zip: Not safe, invokes user defined code (Iterator impl) src/libcore/iter/range.rs ops::Range: Not safe, changes Drop order, but ALREADY HAS SPECIALIZATION ops::RangeInclusive: ditto src/libcore/iter/sources.rs Repeat: Not safe, calling last should iloop. Empty: No point, iterator is at most one item long. Once: ditto OnceWith: ditto src/libcore/option.rs Item: No point, iterator is at most one item long. Iter: ditto IterMut: ditto IntoIter: ditto src/libcore/result.rs Iter: No point, iterator is at most one item long IterMut: ditto IntoIter: ditto src/libcore/slice/mod.rs Split: Not safe, invokes user defined closure SplitMut: ditto RSplit: ditto RSplitMut: ditto Windows: Safe, already has specialization Chunks: ditto ChunksMut: ditto ChunksExact: ditto ChunksExactMut: ditto RChunks: ditto RChunksMut: ditto RChunksExact: ditto RChunksExactMut: ditto src/libcore/str/mod.rs Chars: Safe, already has specialization CharIndices: ditto Bytes: ditto Lines: Safe to call next_back, invokes no user defined code. LinesAny: Deprecated Everything that is generic over P: Pattern: Not safe because Pattern invokes user defined code. SplitWhitespace: Safe to call next_back, invokes no user defined code. SplitAsciiWhitespace: ditto This is attempt 2 of #60130. r? @sfackler
2019-07-02When possible without changing semantics, implement Iterator::last in terms ↵Kyle Huey-0/+8
of DoubleEndedIterator::next_back for types in liballoc and libcore. Provided that the iterator has finite length and does not trigger user-provided code, this is safe. What follows is a full list of the DoubleEndedIterators in liballoc/libcore and whether this optimization is safe, and if not, why not. src/liballoc/boxed.rs Box: Pass through to avoid defeating optimization of the underlying DoubleIterator implementation. This has no correctness impact. src/liballoc/collections/binary_heap.rs Iter: Pass through to avoid defeating optimizations on slice::Iter IntoIter: Not safe, changes Drop order Drain: Not safe, changes Drop order src/liballoc/collections/btree/map.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order Keys: Safe to call next_back, invokes no user defined code. Values: ditto ValuesMut: ditto Range: ditto RangeMut: ditto src/liballoc/collections/btree/set.rs Iter: Safe to call next_back, invokes no user defined code. IntoIter: Not safe, changes Drop order Range: Safe to call next_back, invokes no user defined code. src/liballoc/collections/linked_list.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order src/liballoc/collections/vec_deque.rs Iter: Safe to call next_back, invokes no user defined code. IterMut: ditto IntoIter: Not safe, changes Drop order Drain: ditto src/liballoc/string.rs Drain: Safe because return type is a primitive (char) src/liballoc/vec.rs IntoIter: Not safe, changes Drop order Drain: ditto Splice: ditto src/libcore/ascii.rs EscapeDefault: Safe because return type is a primitive (u8) src/libcore/iter/adapters/chain.rs Chain: Not safe, invokes user defined code (Iterator impl) src/libcore/iter/adapters/flatten.rs FlatMap: Not safe, invokes user defined code (Iterator impl) Flatten: ditto FlattenCompat: ditto src/libcore/iter/adapters/mod.rs Rev: Not safe, invokes user defined code (Iterator impl) Copied: ditto Cloned: Not safe, invokes user defined code (Iterator impl and T::clone) Map: Not safe, invokes user defined code (Iterator impl + closure) Filter: ditto FilterMap: ditto Enumerate: Not safe, invokes user defined code (Iterator impl) Skip: ditto Fuse: ditto Inspect: ditto src/libcore/iter/adapters/zip.rs Zip: Not safe, invokes user defined code (Iterator impl) src/libcore/iter/range.rs ops::Range: Not safe, changes Drop order, but ALREADY HAS SPECIALIZATION ops::RangeInclusive: ditto src/libcore/iter/sources.rs Repeat: Not safe, calling last should iloop. Empty: No point, iterator is at most one item long. Once: ditto OnceWith: ditto src/libcore/option.rs Item: No point, iterator is at most one item long. Iter: ditto IterMut: ditto IntoIter: ditto src/libcore/result.rs Iter: No point, iterator is at most one item long IterMut: ditto IntoIter: ditto src/libcore/slice/mod.rs Split: Not safe, invokes user defined closure SplitMut: ditto RSplit: ditto RSplitMut: ditto Windows: Safe, already has specialization Chunks: ditto ChunksMut: ditto ChunksExact: ditto ChunksExactMut: ditto RChunks: ditto RChunksMut: ditto RChunksExact: ditto RChunksExactMut: ditto src/libcore/str/mod.rs Chars: Safe, already has specialization CharIndices: ditto Bytes: ditto Lines: Safe to call next_back, invokes no user defined code. LinesAny: Deprecated Everything that is generic over P: Pattern: Not safe because Pattern invokes user defined code. SplitWhitespace: Safe to call next_back, invokes no user defined code. SplitAsciiWhitespace: ditto
2019-06-30Improve box clone doctests to ensure the documentation is validChris Gregory-1/+13
2019-06-22Remove FnBox.Mazdak Farrokhzad-79/+0
2019-05-27Update src/liballoc/boxed.rsAleksey Kladov-0/+1
Co-Authored-By: Ralf Jung <post@ralfj.de>
2019-05-27make Box<str>::clone simpler & saferAleksey Kladov-4/+2
2019-05-27avoid materializing unintialized Boxes in RawVecAleksey Kladov-3/+6
2019-05-24Deprecate `FnBox`. `Box<dyn FnOnce()>` can be called directly, since 1.35Simon Sapin-9/+33
FCP completion: https://github.com/rust-lang/rust/issues/28796#issuecomment-439731515
2019-05-23adjust commentRalf Jung-1/+2
2019-05-23Box::into_unique: do the reborrow-to-raw *after* destroying the BoxRalf Jung-4/+4
2019-05-20Create and reference Memory Layout section of boxed docsBrent Kerby-31/+39
2019-05-20Remove trailing whitespaces to satisfy tidyBrent Kerby-5/+5
2019-05-20Update boxed::Box docs on memory layoutBrent Kerby-14/+45
2019-04-23Stabilize futures_apiTaylor Cramer-1/+1
2019-04-15warn(missing_docs) in liballoc, and add missing docsRalf Jung-0/+1
2019-04-11Fix broken links on std::boxed doc pageOliver Middleton-0/+2
2019-04-07Auto merge of #59119 - cramertj:cx-back, r=withoutboatsbors-3/+3
Future-proof the Futures API cc https://github.com/rust-lang/rust/issues/59113, @carllerche, @rust-lang/libs r? @withoutboats
2019-04-05Future-proof the Futures APITaylor Cramer-3/+3
2019-04-05Stabilize boxed_closure_impls in 1.35.0.Charles Lew-9/+3
2019-04-05Remove FnBox specialization of impl FnOnce for Box<impl FnOnce>.Masaki Hara-17/+1
2019-04-05We already have unsized_locals in stage0.Masaki Hara-9/+0
2019-04-05Add Fn* blanket impls for Box.Masaki Hara-0/+33
2019-04-05Make FnBox a subtrait of FnOnce.Masaki Hara-5/+1
2019-03-24Rollup merge of #59328 - koalatux:iter-nth-back, r=scottmcmkennytm-0/+3
Implement specialized nth_back() for Box and Windows. Hi there, this is my first pull request to rust :-) I started implementing some specializations for DoubleEndedIterator::nth_back() and these are the first two. The problem has been discussed in #54054 and nth_back() is tracked in #56995. I'm stuck with the next implementation so I though I do a PR for the ones I'm confident with to get some feedback.
2019-03-09Use lifetime contravariance to elide more lifetimes in core+alloc+stdScott McMurray-4/+4
2019-02-25Rollup merge of #58686 - hellow554:rustfmt_depr, r=cramertjMazdak Farrokhzad-1/+1
replace deprecated rustfmt_skip with rustfmt::skip
2019-02-24Rollup merge of #58183 - jethrogb:jb/alloc-box-guarantees, r=SimonSapinMazdak Farrokhzad-0/+10
Clarify guarantees for `Box` allocation This basically says `Box` does the obvious things for its allocations. See also: https://users.rust-lang.org/t/alloc-crate-guarantees/24981 This may require a T-libs FCP? Not sure. r? @sfackler
2019-02-23replace deprecated rustfmt_skip with rustfmt::skipMarcel Hellwig-1/+1
2019-02-16implement nth_back for BoxAdrian Friedli-0/+3
2019-02-16Rollup merge of #58429 - RalfJung:box, r=TimNNkennytm-3/+8
fix Box::into_unique effecitvely transmuting to a raw ptr Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type. In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
2019-02-13fix Box::into_unique effecitvely transmuting to a raw ptrRalf Jung-3/+8
2019-02-13Clarify guarantees for `Box` allocationJethro Beekman-0/+10
2019-02-03Update the future/task APIMatthias Einwag-3/+3
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592. Changes: - Replacing UnsafeWake with RawWaker and RawWakerVtable - Removal of LocalWaker - Removal of Arc-based Wake trait
2019-02-03liballoc: revert nested imports style changes.Mazdak Farrokhzad-20/+18
2019-02-02liballoc: fix some idiom lints.Mazdak Farrokhzad-3/+3
2019-02-02liballoc: elide some lifetimes.Mazdak Farrokhzad-2/+2
2019-02-02liballoc: refactor & fix some imports.Mazdak Farrokhzad-18/+20
2019-02-02liballoc: cargo check passes on 2018Mazdak Farrokhzad-3/+3
2019-01-27impl Generator for Pin<Box<Generator>>Wim Looman-0/+10
2019-01-27Change generator trait to use pinningWim Looman-7/+6
2019-01-03Add discoverable function for converting Box<T> -> Pin<Box<T>>Wim Looman-4/+14
2019-01-03Allow converting Box<T: !Sized> -> Pin<Box<T>>Wim Looman-1/+1
2018-12-25Remove licensesMark Rousskov-10/+0
2018-12-24Rollup merge of #55470 - daniellimws:box-from-docs, r=CentrilMazdak Farrokhzad-0/+54
box: Add documentation for `From` impls This is a part of #51430. A brief description of the behaviour and examples are added to the documentation. I am not sure what sort of examples to put for the `From` for `Pin` as my [code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=97c908f44e41c9faeffec5b61d72a03e) doesn't even manage to compile using the nightly build. Somehow I feel that I missed out something so do let me know if more information is needed in the documentation or any of the examples require change.
2018-12-21Rename Box/Arc/Rc::pinned to ::pinTaylor Cramer-1/+3
2018-12-21Stabilize PinTaylor Cramer-3/+3
2018-12-20Stabilize `Rc`, `Arc` and `Pin` as method receiversMichael Hewson-1/+6
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use. This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled. This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
2018-12-07Various minor/cosmetic improvements to codeAlexander Regueiro-1/+1
2018-12-05Fix error in example by adding type annotationdaniellimws-1/+1
2018-11-20Incorporate `dyn` into more comments and docs.Corey Farwell-8/+8