about summary refs log tree commit diff
path: root/src/liballoc/sync.rs
AgeCommit message (Collapse)AuthorLines
2020-05-27Rollup merge of #72533 - Diggsey:db-fix-arc-ub2, r=dtolnayDylan DPC-9/+26
Resolve UB in Arc/Weak interaction (2) Use raw pointers to avoid making any assertions about the data field. Follow up from #72479, see that PR for more detail on the motivation. @RalfJung I was able to avoid a lot of the changes to `Weak`, by making a helper type (`WeakInner`) - because of auto-deref and because the fields have the same name, the rest of the code continues to compile.
2020-05-25Fix UB in ArcDiggory Blake-9/+26
Use raw pointers to avoid making any assertions about the data field.
2020-05-19Auto merge of #71447 - cuviper:unsized_cow, r=dtolnaybors-0/+16
impl From<Cow> for Box, Rc, and Arc These forward `Borrowed`/`Owned` values to existing `From` impls. - `Box<T>` is a fundamental type, so it would be a breaking change to add a blanket impl. Therefore, `From<Cow>` is only implemented for `[T]`, `str`, `CStr`, `OsStr`, and `Path`. - For `Rc<T>` and `Arc<T>`, `From<Cow>` is implemented for everything that implements `From` the borrowed and owned types separately.
2020-05-17Auto merge of #72204 - RalfJung:abort, r=Mark-Simulacrumbors-0/+5
make abort intrinsic safe, and correct its documentation Turns out `std::process::abort` is not the same as the intrinsic, the comment was just wrong. Quoting from the unix implementation: ``` // On Unix-like platforms, libc::abort will unregister signal handlers // including the SIGABRT handler, preventing the abort from being blocked, and // fclose streams, with the side effect of flushing them so libc buffered // output will be printed. Additionally the shell will generally print a more // understandable error message like "Abort trap" rather than "Illegal // instruction" that intrinsics::abort would cause, as intrinsics::abort is // implemented as an illegal instruction. ```
2020-05-17make abort intrinsic safe, and correct its documentationRalf Jung-0/+5
2020-05-14Auto merge of #71321 - matthewjasper:alloc-min-spec, r=sfacklerbors-27/+13
Use min_specialization in liballoc - Remove a type parameter from `[A]RcFromIter`. - Remove an implementation of `[A]RcFromIter` that didn't actually specialize anything. - Remove unused implementation of `IsZero` for `Option<&mut T>`. - Change specializations of `[A]RcEqIdent` to use a marker trait version of `Eq`. - Remove `BTreeClone`. I couldn't find a way to make this work with `min_specialization`. - Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`. After this only libcore is the only standard library crate using `feature(specialization)`. cc #31844
2020-05-14Fix Arc::decr_strong_count doc testTomasz Miąsko-3/+5
2020-05-07Rollup merge of #70733 - yoshuawuyts:arc-increment-refcount, r=Mark-SimulacrumDylan DPC-0/+73
Add Arc::{incr,decr}_strong_count This adds two `unsafe` methods to `Arc`: `incr_strong_count` and `decr_strong_count`. A suggestion to add methods to change the strong count in `Arc` came up in during review in https://github.com/rust-lang/rust/pull/68700#discussion_r396169064, and from asking a few people this seemed like generally useful to have. References: - [Motivation from #68700](https://github.com/rust-lang/rust/pull/68700#discussion_r396169064) - [Real world example in an executor](https://docs.rs/extreme/666.666.666666/src/extreme/lib.rs.html#13)
2020-05-07Add Arc::{incr,decr}_strong_countYoshua Wuyts-0/+73
2020-04-26Use min_specialization in liballocMatthew Jasper-27/+13
- Remove a type parameter from `[A]RcFromIter`. - Remove an implementation of `[A]RcFromIter` that didn't actually specialize anything. - Remove unused implementation of `IsZero` for `Option<&mut T>`. - Change specializations of `[A]RcEqIdent` to use a marker trait version of `Eq`. - Remove `BTreeClone`. I couldn't find a way to make this work with `min_specialization`. - Add `rustc_unsafe_specialization_marker` to `Copy` and `TrustedLen`.
2020-04-25Auto merge of #71556 - Dylan-DPC:rollup-9ll4shr, r=Dylan-DPCbors-1/+3
Rollup of 7 pull requests Successful merges: - #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`) - #69813 (Implement BitOr and BitOrAssign for the NonZero integer types) - #70712 (stabilize BTreeMap::remove_entry) - #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`) - #71544 (Replace filter_map().next() calls with find_map()) - #71545 (Fix comment in docstring example for Error::kind) - #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.) Failed merges: r? @ghost
2020-04-25Rollup merge of #71168 - SimonSapin:into_raw_non_null, r=AmanieuDylan DPC-1/+3
Deprecate `{Box,Rc,Arc}::into_raw_non_null` Per ongoing FCP at https://github.com/rust-lang/rust/issues/47336#issuecomment-586589016 See also https://github.com/rust-lang/rust/issues/47336#issuecomment-614054164
2020-04-25Bump bootstrap compilerMark Rousskov-1/+0
2020-04-23Fix doc link errorsTyler Ruckinger-1/+1
2020-04-22impl From<Cow> for Rc and ArcJosh Stone-0/+16
These forward `Borrowed`/`Owned` values to existing `From` impls. impl<'a, B> From<Cow<'a, B>> for Rc<B> where B: ToOwned + ?Sized, Rc<B>: From<&'a B> + From<B::Owned>, impl<'a, B> From<Cow<'a, B>> for Arc<B> where B: ToOwned + ?Sized, Arc<B>: From<&'a B> + From<B::Owned>,
2020-04-19weak-into-raw: Add {Arc,Rc}::as_ptrMichal 'vorner' Vaner-1/+25
For consistency with Weak
2020-04-15Apply suggestions from code reviewSimon Sapin-1/+1
Co-Authored-By: Ralf Jung <post@ralfj.de>
2020-04-15Deprecate `Rc::into_raw_non_null` and `Arc::into_raw_non_null`Simon Sapin-0/+2
2020-04-15Deprecate `Box::into_raw_non_null`Simon Sapin-1/+1
Per https://github.com/rust-lang/rust/issues/47336#issuecomment-586589016
2020-04-13weak-into-raw: as_raw -> as_ptr + dangling garbageMichal 'vorner' Vaner-26/+15
* Rename Weak::as_raw to Weak::as_ptr for consistency with some other types. * The as_ptr for a dangling Weak pointer might return whatever garbage (and takes that advantage to avoid a conditional). * Don't guarantee to be able to do `Weak::from_raw(weak.as_ptr())` (even though it'll still work fine).
2020-04-08Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.Eduard-Mihai Burtescu-1/+2
2020-04-05Stop importing integer modules in liballocLinus Färnstrand-1/+0
2020-03-28Make fields in `MemoryBlock` publicTim Diekmann-1/+1
2020-03-26Remove alignment from `MemoryBlock`Tim Diekmann-9/+3
2020-03-26Fix issues from review and unsoundness of `RawVec::into_box`Tim Diekmann-5/+11
2020-03-26Overhaul of the `AllocRef` trait to match allocator-wg's latest consensTim Diekmann-2/+4
2020-03-22Rollup merge of #68099 - lukaslueg:into_raw_unsafe, r=LukasKalbertodtDylan DPC-5/+18
Amend Rc/Arc::from_raw() docs regarding unsafety [This](https://stackoverflow.com/questions/59671647/is-it-safe-to-clone-a-type-erased-arc-via-raw-pointer) question on SO boils down to "is it safe to `::from_raw()` a `Rc<T>`/`Arc<T>` using a dummy `T` even if `T` is never dereferenced via the new `Rc`/`Arc`?". It almost never is. This PR amends the docs of `from_raw()` regarding this point.
2020-03-20Make std::sync::Arc compatible with ThreadSanitizerTomasz Miąsko-4/+21
The memory fences used previously in Arc implementation are not properly understood by ThreadSanitizer as synchronization primitives. This had unfortunate effect where running any non-trivial program compiled with `-Z sanitizer=thread` would result in numerous false positives. Replace acquire fences with acquire loads when using ThreadSanitizer to address the issue.
2020-03-03Rollup merge of #69609 - TimDiekmann:excess, r=AmanieuYuki Okushi-1/+1
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-1/+1
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 16:50:34 +0000