about summary refs log tree commit diff
path: root/src/liballoc/sync.rs
AgeCommit message (Collapse)AuthorLines
2020-05-29Rollup merge of #72288 - vorner:stabilize-weak-into-raw, r=dtolnayYuki Okushi-12/+4
Stabilization of weak-into-raw Closes #60728. There are also two removals of `#![feature(weak_into_raw)]` in the `src/tools/miri` submodule. How should I synchronize the changes with there? * I can ignore it for now and once this gets merged, update the tool, send a pull request to that one and then reference the changes to rustc. * I could try submitting the changes to miri first, but then the build would fail there, because the attribute would still be needed. I think the first one is the correct one, extrapolating from the contributing guidelines (even though they speak about breaking the tools and this should not break it, as extra feature should not hurt).
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-17Stabilization of weak-into-rawMichal 'vorner' Vaner-12/+4
Stabilizes #60728.
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 17:57:01 +0000