about summary refs log tree commit diff
path: root/src/liballoc/boxed.rs
AgeCommit message (Collapse)AuthorLines
2020-04-26Rollup merge of #71421 - elichai:2020-04-boxed-slice, r=sfacklerDylan DPC-0/+10
Add a function to turn Box<T> into Box<[T]> Hi, I think this is very useful, as currently it's not possible in safe rust to do this without re-allocating. an alternative implementation of the same function can be: ```rust pub fn into_boxed_slice<T>(boxed: Box<T>) -> Box<[T]> { unsafe { let slice = slice::from_raw_parts_mut(Box::into_raw(boxed), 1); Box::from_raw(slice) } } ``` The only thing that makes me a little uncomfortable is this line : > The alignment of array types is greater or equal to the alignment of its element type from https://rust-lang.github.io/unsafe-code-guidelines/layout/arrays-and-slices.html But then I see: > The alignment of &T, &mut T, *const T and *mut T are the same, and are at least the word size. > The alignment of &[T] is the word size. from https://rust-lang.github.io/unsafe-code-guidelines/layout/pointers.html#representation So I do believe this is valid(FWIW it also passes in miri https://play.rust-lang.org/?gist=c002b99364ee6b29862aeb3565a91c19)
2020-04-26Add a function to turn Box<T> into Box<[T]> (into_boxed_slice)Elichai Turkel-0/+10
2020-04-16Implement `Box::into_raw` based on `Box::leak`Simon Sapin-10/+17
… instead of the other way around.
2020-04-15Apply suggestions from code reviewSimon Sapin-1/+1
Co-Authored-By: Ralf Jung <post@ralfj.de>
2020-04-15Deprecate `Box::into_raw_non_null`Simon Sapin-12/+21
Per https://github.com/rust-lang/rust/issues/47336#issuecomment-586589016
2020-04-04use ManuallyDrop instead of forget inside collectionsTrevor Spiteri-1/+1
This commit changes some usage of mem::forget into mem::ManuallyDrop in some Vec, VecDeque, BTreeMap and Box methods. Before the commit, the generated IR for some of the methods was longer, and even after optimization, some unwinding artifacts were still present.
2020-03-28Make fields in `MemoryBlock` publicTim Diekmann-2/+2
2020-03-26Fix issues from review and unsoundness of `RawVec::into_box`Tim Diekmann-11/+4
2020-03-26Overhaul of the `AllocRef` trait to match allocator-wg's latest consensTim Diekmann-23/+21
2020-03-15Bump the bootstrap compilerJonas Schievink-24/+0
2020-03-03Rollup merge of #69609 - TimDiekmann:excess, r=AmanieuYuki Okushi-2/+2
Remove `usable_size` APIs This removes the usable size APIs: - remove `usable_size` (obv) - change return type of allocating methods to include the allocated size - remove `_excess` API r? @Amanieu closes rust-lang/wg-allocators#17
2020-03-03Remove `usable_size` APIsTim Diekmann-2/+2
2020-02-28Stabilize `boxed_slice_try_from`Yuki Okushi-1/+1
2020-02-11Preparation for allocator aware `Box`Tim Diekmann-15/+16
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-02Add a resume type parameter to `Generator`Jonas Schievink-0/+24
2020-01-31Fixed issue 68593hman523-1/+2
2020-01-27Rename `Alloc` to `AllocRef`Tim Diekmann-1/+1
2019-12-23Simplify Clone for Box<[T]>Josh Stone-42/+1
The bespoke `BoxBuilder` was basically a very simple `Vec`. Instead, let's clone to a real `Vec`, with all of its specialization for the task, then convert back to `Box<[T]>`.
2019-12-22Format the worldMark Rousskov-23/+13
2019-12-21Require issue = "none" over issue = "0" in unstable attributesRoss MacArthur-4/+4
2019-12-12Rollup merge of #62514 - stephaneyfx:box-ffi, r=nikomatsakisYuki Okushi-0/+53
Clarify `Box<T>` representation and its use in FFI This officializes what was only shown as a code example in [the unsafe code guidelines](https://rust-lang.github.io/unsafe-code-guidelines/layout/function-pointers.html?highlight=box#use) and follows [the discussion](https://github.com/rust-lang/unsafe-code-guidelines/issues/157) in the corresponding repository. It is also related to [the issue](https://github.com/rust-lang/rust/issues/52976) regarding marking `Box<T>` `#[repr(transparent)]`. If the statement this PR adds is incorrect or a more in-depth discussion is warranted, I apologize. Should it be the case, the example in the unsafe code guidelines should be amended and some document should make it clear that it is not sound/supported.
2019-12-11clarify that `Box<T>` should only be used when defined *in Rust*Nicholas Matsakis-7/+16
2019-12-10Fix description based on reviewStephane Raux-1/+1
2019-12-10Remove trailing whitespaceStephane Raux-4/+4
2019-12-09Specify behavior when passed a null pointerStephane Raux-2/+6
2019-12-09Use Niko's wordingStephane Raux-2/+21
2019-11-05alloc: Add new_zeroed() versions like new_uninit().Emilio Cobos Álvarez-0/+27
MaybeUninit has both uninit() and zeroed(), it seems reasonable to have the same surface on Box/Rc/Arc. Needs tests.
2019-11-01Update FFI exampleStephane Raux-4/+4
- Use meaningful names - Clarify comments - Fix C function declaration
2019-10-16Uninitialized boxes: check for zero-size allocation based on Layout::sizeSimon Sapin-4/+4
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-01Remove unneeded `fn main` blocks from docsLzu Tao-33/+21
2019-08-25Update Box representation comment based on reviewsStephane Raux-3/+2
2019-08-17Doc nitsSimon Sapin-4/+4
Co-Authored-By: Ralf Jung <post@ralfj.de>
2019-08-16Add tracking issue numbersSimon Sapin-4/+4
2019-08-16Use `alloc::Global` in `Box::new_uninit`Simon Sapin-4/+6
2019-08-16Fix intra-rustdoc linksSimon Sapin-0/+4
2019-08-16Move constructors of boxed/rc’ed slices to matching `impl` blocksSimon Sapin-10/+12
2019-08-16Add new_uninit_slice and assume_init on Box, Rc, and Arc of [T]Simon Sapin-4/+70
2019-08-16Add new_uninit and assume_init on Box, Rc, and ArcSimon Sapin-0/+61
2019-08-05Add implementations for converting boxed slices into boxed arraysJake Goulding-1/+18
This mirrors the implementations of reference slices into arrays.
2019-07-26Rollup merge of #62310 - GuillaumeGomez:add-missing-doc-links-boxed, r=CentrilMazdak Farrokhzad-5/+9
Add missing doc links in boxed module r? @rust-lang/docs
2019-07-09Clarify `Box<T>` representation and its use in FFIStephane Raux-0/+22
This officializes what was only shown as a code example in [the unsafe code guidelines](https://rust-lang.github.io/unsafe-code-guidelines/layout/function-pointers.html?highlight=box#use) and follows [the discussion](https://github.com/rust-lang/unsafe-code-guidelines/issues/157) in the corresponding repository. It is also related to [the issue](https://github.com/rust-lang/rust/issues/52976) regarding marking `Box<T>` `#[repr(transparent)]`.
2019-07-04Add missing doc links in boxed moduleGuillaume Gomez-5/+9
2019-07-04Add tracking issue for Box::into_pinWim Looman-1/+1
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-23 01:50:46 +0000