about summary refs log tree commit diff
path: root/src/liballoc/sync.rs
AgeCommit message (Collapse)AuthorLines
2020-02-28Stabilize `boxed_slice_try_from`Yuki Okushi-1/+1
2020-02-07Make rc::RcBox and sync::ArcInner repr(C)Lukas Lueg-0/+4
Future-proof these types in case rustc reorders the inner fields. As per discussion in PR #68099.
2020-01-28Refine [Arc/Rc]::from_raw() docsLukas Lueg-5/+13
2020-01-27Rename `Alloc` to `AllocRef`Tim Diekmann-1/+1
2020-01-16Auto merge of #67339 - CAD97:rc-provenance, r=sfacklerbors-2/+12
Use pointer offset instead of deref for A/Rc::into_raw Internals thread: https://internals.rust-lang.org/t/rc-and-internal-mutability/11463/2?u=cad97 The current implementation of (`A`)`Rc::into_raw` uses the `Deref::deref` implementation to get the pointer-to-data that is returned. This is problematic in the proposed Stacked Borrow rules, as this only gets shared provenance over the data location. (Note that the strong/weak counts are `UnsafeCell` (`Cell`/`Atomic`) so shared provenance can still mutate them, but the data itself is not.) When promoted back to a real reference counted pointer, the restored pointer can be used for mutation through `::get_mut` (if it is the only surviving reference). However, this mutates through a pointer ultimately derived from a `&T` borrow, violating the Stacked Borrow rules. There are three known potential solutions to this issue: - Stacked Borrows is wrong, liballoc is correct. - Fully admit (`A`)`Rc` as an "internal mutability" type and store the data payload in an `UnsafeCell` like the strong/weak counts are. (Note: this is not needed generally since the `RcBox`/`ArcInner` is stored behind a shared `NonNull` which maintains shared write provenance as a raw pointer.) - Adjust `into_raw` to do direct manipulation of the pointer (like `from_raw`) so that it maintains write provenance and doesn't derive the pointer from a reference. This PR implements the third option, as recommended by @RalfJung. Potential future work: provide `as_raw` and `clone_raw` associated functions to allow the [`&T` -> (`A`)`Rc<T>` pattern](https://internals.rust-lang.org/t/rc-and-internal-mutability/11463/2?u=cad97) to be used soundly without creating (`A`)`Rc` from references.
2020-01-10Ammend Rc/Arc::from_raw() docs regarding unsafetyLukas Lueg-3/+4
Constructing an Rc/Arc is unsafe even if the wrapped `T` is never dereferenced.
2019-12-22Format the worldMark Rousskov-95/+56
2019-12-22Rollup merge of #67504 - Mark-Simulacrum:note-data-offset, r=CentrilMazdak Farrokhzad-0/+2
Warn against relying on ?Sized being last Fixes #62522
2019-12-21Warn against relying on ?Sized being lastMark Rousskov-0/+2
2019-12-21Require issue = "none" over issue = "0" in unstable attributesRoss MacArthur-4/+4
2019-12-17Add internal safety docs to (A)Rc::into_rawCAD97-0/+5
2019-12-16Rollup merge of #65778 - bdonlan:stable_weak_count, r=dtolnayMazdak Farrokhzad-25/+15
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-15Use pointer offset instead of deref for A/Rc::into_rawcad97-2/+7
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-23/+13
2019-11-21Stabilize `std::{rc,sync}::Weak::{weak_count, strong_count}`Bryan Donlan-2/+2
Closes: #57977
2019-11-09Remove Layout::pad_to_unlign 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-22Apply clippy::needless_return suggestionsMateusz Mikuła-1/+1
2019-10-19do all the same edits with ArcRalf Jung-51/+65
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-6/+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-3/+3
2019-08-25Stabilise weak_ptr_eqThomas de Zeeuw-3/+1
2019-08-19Rollup merge of #63252 - nrc:arc-doc, r=alexcrichtonMazdak Farrokhzad-4/+0
Remove recommendation about idiomatic syntax for Arc::clone I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs. The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls. Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional. The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years. The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case). cc @nical (who added the docs in the first place; sorry :-) ) r? @alexcrichton (or someone else on @rust-lang/libs )
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-04Remove recommendation about idiomatic syntax for Arc::CloneNick Cameron-4/+0
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2019-08-02liballoc: Unconfigure tests during normal buildVadim Petrochenkov-483/+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-66/+198
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-16/+16
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 17:07:16 +0000