about summary refs log tree commit diff
path: root/src/liballoc/sync.rs
AgeCommit message (Collapse)AuthorLines
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
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/Arc: Use specialization to elide allocation.Mazdak Farrokhzad-40/+167
2019-06-20Arc: refactor data_offset{_sized}.Mazdak Farrokhzad-8/+9
2019-06-20Arc: refactor away PhantomData noise.Mazdak Farrokhzad-15/+21
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-13docs: Use String in Rc::into_raw examplesMichal 'vorner' Vaner-14/+14
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:-).
2019-05-26sync::Weak::{as,from,into}_rawMichal 'vorner' Vaner-6/+158
Methods on the Weak to access it as raw pointer to the data.
2019-05-11add comment to `Rc`/`Arc`'s `Eq` specializationThomas Heck-0/+5
2019-04-18make liballoc internal test suite mostly pass in MiriRalf Jung-0/+2
2019-02-10libs: doc commentsAlexander Regueiro-4/+4
2019-02-03liballoc: revert nested imports style changes.Mazdak Farrokhzad-42/+36
2019-02-02liballoc: fix some idiom lints.Mazdak Farrokhzad-4/+4
2019-02-02liballoc: elide some lifetimes.Mazdak Farrokhzad-2/+2
2019-02-02liballoc: adjust abolute imports + more import fixes.Mazdak Farrokhzad-2/+1
2019-02-02liballoc: refactor & fix some imports.Mazdak Farrokhzad-39/+42
2019-02-02liballoc: cargo check passes on 2018Mazdak Farrokhzad-5/+5
2019-01-31Auto merge of #56696 - jonas-schievink:weak-counts, r=alexcrichtonbors-1/+83
Implement Weak::{strong_count, weak_count} The counters are also useful on `Weak`, not just on strong references (`Rc` or `Arc`). In situations where there are still strong references around, you can also get these counts by temporarily upgrading and adjusting the values accordingly. Using the methods introduced here is simpler to do, less error-prone (since you can't forget to adjust the counts), can also be used when no strong references are around anymore, and might be more efficient due to not having to temporarily create an `Rc`. This is mainly useful in assertions or tests of complex data structures. Data structures might have internal invariants that make them the sole owner of a `Weak` pointer, and an assertion on the weak count could be used to ensure that this indeed happens as expected. Due to the presence of `Weak::upgrade`, the `strong_count` becomes less useful, but it still seems worthwhile to mirror the API of `Rc`. TODO: * [X] Tracking issue - https://github.com/rust-lang/rust/issues/57977 Closes https://github.com/rust-lang/rust/issues/50158
2019-01-29Add tracking issue to unstable attributeJonas Schievink-2/+2
2019-01-29Make weak_count return an Option<usize>Jonas Schievink-12/+10
2019-01-29Implement a slightly racy `sync::Weak::weak_count`Jonas Schievink-5/+70
2019-01-29Implement Weak::{strong_count, weak_count}Jonas Schievink-0/+19
2019-01-28Introduce into_raw_non_null on Rc and ArcDale Wijnand-0/+21
2018-12-25Remove licensesMark Rousskov-10/+0
2018-12-23Rollup merge of #56939 - cramertj:pin-stabilization, r=alexcrichtonMazdak Farrokhzad-3/+5
Pin stabilization This implements the changes suggested in https://github.com/rust-lang/rust/issues/55766#issue-378417538 and stabilizes the `pin` feature. @alexcrichton also listed several "blockers" in that issue, but then in [this comment](https://github.com/rust-lang/rust/issues/55766#issuecomment-445074980) mentioned that they're more "TODO items": > In that vein I think it's fine for a stabilization PR to be posted at any time now with FCP lapsed for a week or so now. The final points about self/pin/pinned can be briefly discussed there (if even necessary, they could be left as the proposal above). Let's settle these last bits here and get this thing stabilized! :) r? @alexcrichton cc @withoutboats
2018-12-23Rollup merge of #56941 - euclio:deny-libstd-resolution-failures, ↵kennytm-1/+4
r=QuietMisdreavus deny intra-doc link resolution failures in libstd Fixes #56693. Until we land a fix for the underlying issue (#56922), we can at least fix the failures in libstd so they don't propagate to downstream crates.
2018-12-21Rename Box/Arc/Rc::pinned to ::pinTaylor Cramer-1/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 07:04:06 +0000