summary refs log tree commit diff
path: root/src/liballoc/rc.rs
AgeCommit message (Collapse)AuthorLines
2019-12-16Rollup merge of #65778 - bdonlan:stable_weak_count, r=dtolnayMazdak Farrokhzad-10/+6
Stabilize `std::{rc,sync}::Weak::{weak_count, strong_count}` * Original PR: #56696 * Tracking issue: #57977 Closes: #57977 Supporting comments: > Although these were added for testing, it is occasionally useful to have a way to probe optimistically for whether a weak pointer has become dangling, without actually taking the overhead of manipulating atomics. Are there any plans to stabilize this? _Originally posted by @bdonlan in https://github.com/rust-lang/rust/issues/57977#issuecomment-516970921_ > Having this stabilized would help. Currently, the only way to check if a weak pointer has become dangling is to call `upgrade`, which is by far expensive. _Originally posted by @glebpom in https://github.com/rust-lang/rust/issues/57977#issuecomment-526934709_ Not sure if stabilizing these warrants a full RFC, so throwing this out here as a start for now. Note: per CONTRIBUTING.md, I ran the tidy checks, but they seem to be failing on unchanged files (primarily in `src/stdsimd`).
2019-12-14Bump Weak::strong_count/weak_count stabilizations from 1.40 to 1.41David Tolnay-2/+2
2019-12-05Rollup merge of #66710 - vorner:weak-into-raw-null-docs, r=dtolnayMazdak Farrokhzad-10/+14
weak-into-raw: Clarify some details in Safety Clarify it is OK to pass a pointer that never owned a weak count (one from Weak::new) back into it as it was created from it. Relates to discussion in #60728. @CAD97 Do you want to have a look at the new docs?
2019-12-05weak-into-raw: Clarify some details in SafetyMichal 'vorner' Vaner-10/+14
Clarify it is OK to pass a pointer that never owned a weak count (one from Weak::new) back into it as it was created from it. Relates to discussion in #60728.
2019-12-03Auto merge of #66256 - CAD97:patch-2, r=RalfJungbors-1/+1
Layout::pad_to_align is infallible As per [this comment](https://github.com/rust-lang/rust/issues/55724#issuecomment-441421651) (cc @glandium). > Per https://github.com/rust-lang/rust/blob/eb981a1/src/libcore/alloc.rs#L63-L65, `layout.size()` is always <= `usize::MAX - (layout.align() - 1)`. > > Which means: > > * The maximum value `layout.size()` can have is already aligned for `layout.align()` (`layout.align()` being a power of two, `usize::MAX - (layout.align() - 1)` is a multiple of `layout.align()`) > * Incidentally, any value smaller than that maximum value will align at most to that maximum value. > > IOW, `pad_to_align` can not return `Err(LayoutErr)`, except for the layout not respecting its invariants, but we shouldn't care about that. This PR makes `pad_to_align` return `Layout` directly, representing the fact that it cannot fail.
2019-11-26Rollup merge of #66128 - emilio:new-zeroed, r=SimonSapinTyler Mandry-0/+29
alloc: Add new_zeroed() versions like new_uninit(). MaybeUninit has both uninit() and zeroed(), it seems reasonable to have the same surface on Box/Rc/Arc. Needs tests. cc #63291
2019-11-21Make Weak::weak_count() return zero when no strong refs remainBryan Donlan-8/+4
2019-11-21Stabilize `std::{rc,sync}::Weak::{weak_count, strong_count}`Bryan Donlan-2/+2
Closes: #57977
2019-11-09Remove Layout::pad_to_align unwrapChristopher Durham-1/+1
2019-11-05Reverted PhantomData in LinkedList, fixed PhantomData markers in Rc and ArcOleg Nosov-1/+1
2019-11-05alloc: Add new_zeroed() versions like new_uninit().Emilio Cobos Álvarez-0/+29
MaybeUninit has both uninit() and zeroed(), it seems reasonable to have the same surface on Box/Rc/Arc. Needs tests.
2019-10-19some more Rc tweaksRalf Jung-10/+12
2019-10-19the exampleis about drop, not (de)allocationRalf Jung-2/+2
2019-10-17more consistency and clarificationRalf Jung-13/+17
2019-10-17Rc: value -> allocationRalf Jung-44/+51
2019-10-13Fix typo in docs for `Rc`kalabukdima-2/+2
2019-10-01Remove unneeded `fn main` blocks from docsLzu Tao-5/+3
2019-09-14Rollup merge of #61797 - Thomasdezeeuw:stablise-weak_ptr_eq, r=RalfJungMazdak Farrokhzad-5/+4
Stabilise weak_ptr_eq Implemented in #55987. Closes #55981.
2019-09-06A few cosmetic improvements to code & comments in liballoc and libcoreAlexander Regueiro-1/+1
2019-08-25Update {rc, sync}::Weak::ptr_eq doc about comparing Weak::newThomas de Zeeuw-2/+3
2019-08-25Stabilise weak_ptr_eqThomas de Zeeuw-3/+1
2019-08-17Rename private helper method allocate_for_unsized to allocate_for_layoutSimon Sapin-5/+5
2019-08-17Doc nitsSimon Sapin-5/+5
Co-Authored-By: Ralf Jung <post@ralfj.de>
2019-08-16Relax the safety condition for get_mut_uncheckedSimon Sapin-2/+4
2019-08-16Reuse more internal Rc and Arc methodsSimon Sapin-35/+7
2019-08-16Add a comment on the usage of Layout::new::<RcBox<()>>()Simon Sapin-0/+2
2019-08-16Add tracking issue numbersSimon Sapin-5/+5
2019-08-16Use ManuallyDrop instead of mem::forgetSimon Sapin-6/+2
Per https://github.com/rust-lang/rust/pull/62451#discussion_r303197278
2019-08-16Fix intra-rustdoc linksSimon Sapin-1/+5
2019-08-16Move constructors of boxed/rc’ed slices to matching `impl` blocksSimon Sapin-45/+47
2019-08-16Add new_uninit_slice and assume_init on Box, Rc, and Arc of [T]Simon Sapin-5/+93
2019-08-16Add new_uninit and assume_init on Box, Rc, and ArcSimon Sapin-0/+81
2019-08-16Add Rc::get_mut_unchecked, Arc::get_mut_uncheckedSimon Sapin-1/+30
2019-08-05Add implementations for converting boxed slices into boxed arraysJake Goulding-1/+18
This mirrors the implementations of reference slices into arrays.
2019-08-02liballoc: Unconfigure tests during normal buildVadim Petrochenkov-430/+3
Remove additional libcore-like restrictions from liballoc, turns out the testing works ok if the tests are a part of liballoc itself.
2019-07-18Fix clippy::clone_on_copy warningsMateusz Mikuła-1/+1
2019-07-13Auto merge of #61953 - Centril:shared-from-iter, r=RalfJungbors-74/+213
Add `impl<T> FromIterator<T> for Arc/Rc<[T]>` Add implementations of `FromIterator<T> for Arc/Rc<[T]>` with symmetrical logic. This also takes advantage of specialization in the case of iterators with known length (`TrustedLen`) to elide the final allocation/copying from a `Vec<T>` into `Rc<[T]>` because we can allocate the space for the `Rc<[T]>` directly when the size is known. This is the primary motivation and why this is to be preferred over `iter.collect::<Vec<_>>().into(): Rc<[T]>`. Moreover, this PR does some refactoring in some places. r? @RalfJung for the code cc @alexcrichton from T-libs
2019-07-06Rollup merge of #61862 - vorner:weak-into-raw-methods, r=sfacklerMazdak Farrokhzad-15/+15
Make the Weak::{into,as}_raw methods Because Weak doesn't Deref, so there's no reason for them to be only associated methods. As kindly pointed out here https://github.com/rust-lang/rust/pull/60766#issuecomment-501706422 by @chpio.
2019-06-21shared_from_iter: Polish internal docs.Mazdak Farrokhzad-14/+15
2019-06-20shared_from_iter: Clarify slice::Iter specialization impl.Mazdak Farrokhzad-2/+8
2019-06-20data_offset_align: add inline attribute.Mazdak Farrokhzad-0/+1
2019-06-20deduplicate slice_from_raw_parts_mut.Mazdak Farrokhzad-17/+1
2019-06-20shared_from_iter/Rc: Use specialization to elide allocation.Mazdak Farrokhzad-39/+167
2019-06-20Rc: reduce duplicate calls.Mazdak Farrokhzad-4/+8
2019-06-20Rc: refactor data_offset{_sized}.Mazdak Farrokhzad-6/+7
2019-06-20Rc: refactor away PhantomData noise.Mazdak Farrokhzad-23/+30
2019-06-20Add basic 'shared_from_iter' impls.Mazdak Farrokhzad-0/+7
2019-06-16make `Weak::ptr_eq`s into methodsThomas Heck-7/+7
2019-06-15Make the Weak::{into,as}_raw methodsMichal 'vorner' Vaner-15/+15
Because Weak doesn't Deref, so there's no reason for them to be only associated methods.
2019-06-14Auto merge of #61421 - vorner:string-in-rc-into-raw-docs, r=RalfJungbors-14/+14
docs: Use String in Rc::into_raw examples It is unclear if accessing an integer after `drop_in_place` has been called on it is undefined behaviour or not, as demonstrated by the discussion in https://github.com/rust-lang/rust/pull/60766#pullrequestreview-243414222. Avoid these uncertainties by using String which frees memory in its `drop_in_place` to make sure this is undefined behaviour. The message in the docs should be to watch out and not access the data after that, not discussing when one maybe could get away with it O:-).
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 21:38:05 +0000