about summary refs log tree commit diff
path: root/library/alloc/src/sync.rs
AgeCommit message (Collapse)AuthorLines
2021-10-11Rollup merge of #89726 - jkugelman:must-use-alloc-constructors, r=joshtriplettGuillaume Gomez-0/+6
Add #[must_use] to alloc constructors Added `#[must_use]`. to the various forms of `new`, `pin`, and `with_capacity` in the `alloc` crate. No extra explanations given as I couldn't think of anything useful to add. I figure this deserves extra scrutiny compared to the other PRs I've done so far. In particular: * The 4 `pin`/`pin_in` methods I touched. Are there legitimate use cases for pinning and not using the result? Pinning's a difficult concept I'm not very comfortable with. * `Box`'s constructors. Do people ever create boxes just for the side effects... allocating or zeroing out memory? Parent issue: #89692 r? ``@joshtriplett``
2021-10-10Add #[must_use] to conversions that move selfJohn Kugelman-0/+3
2021-10-10Add #[must_use] to alloc constructorsJohn Kugelman-0/+6
2021-09-25Apply 16 commits (squashed)Frank Steffahn-12/+12
---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::fmt ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::{rc, sync} ---------- Fix spacing for links inside code blocks, and improve link tooltips in alloc::string ---------- Fix spacing for links inside code blocks in alloc::vec ---------- Fix spacing for links inside code blocks in core::option ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in core::result ---------- Fix spacing for links inside code blocks in core::{iter::{self, iterator}, stream::stream, poll} ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{fs, path} ---------- Fix spacing for links inside code blocks in std::{collections, time} ---------- Fix spacing for links inside code blocks in and make formatting of `&str`-like types consistent in std::ffi::{c_str, os_str} ---------- Fix spacing for links inside code blocks, and improve link tooltips in std::ffi ---------- Fix spacing for links inside code blocks, and improve a few link tooltips in std::{io::{self, buffered::{bufreader, bufwriter}, cursor, util}, net::{self, addr}} ---------- Fix typo in link to `into` for `OsString` docs ---------- Remove tooltips that will probably become redundant in the future ---------- Apply suggestions from code review Replacing `…std/primitive.reference.html` paths with just `reference` Co-authored-by: Joshua Nelson <github@jyn.dev> ---------- Also replace `…std/primitive.reference.html` paths with just `reference` in `core::pin`
2021-08-24Make explanations of cross-references between `make_mut` and `get_mut` more ↵Frank Steffahn-2/+3
accurate
2021-08-24Clarifiy weak pointers being diassociated…Frank Steffahn-2/+3
…noting the fact that `clone` is not called. Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
2021-08-19Adjust documentation of `Arc::make_mut`Frank Steffahn-9/+25
Related discussion in the users forum: https://users.rust-lang.org/t/what-s-this-alleged-difference-between-arc-make-mut-and-rc-make-mut/63747?u=steffahn Also includes small formatting improvement in the documentation of `Rc::make_mut`. This commit makes the two documentations in question complete analogs. The previously claimed point in which one "differs from the behavior of" the other turns out to be incorrect, AFAIK. One remaining inaccuracy: `Weak` pointers aren't disassociated from the allocation but only from the contained value, i.e. in case of outstanding `Weak` pointers there still is a new allocation created, just the call to `.clone()` is avoided, instead the value is moved from one allocation to the other.
2021-07-31Relocate Arc and Rc UnwindSafe implsDavid Tolnay-0/+4
2021-07-29Fix may not to appropriate might not or must notAli Malik-3/+3
2021-07-15Added Arc::try_pinAlex Gaynor-1/+7
This helper is in line with other other allocation helpers on Arc.
2021-07-02alloc: `no_global_oom_handling`: disable `new()`s, `pin()`s, etc.Miguel Ojeda-0/+6
They are infallible, and could not be actually used because they will trigger an error when monomorphized, but it is better to just remove them. Link: https://github.com/Rust-for-Linux/linux/pull/402 Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2021-06-17Rollup merge of #85663 - fee1-dead:document-arc-from, r=m-ou-seYuki Okushi-0/+14
Document Arc::from
2021-06-05Document Arc::fromDeadbeef-0/+14
2021-05-26Rollup merge of #85666 - fee1-dead:document-shared-from-cow, r=dtolnayYuki Okushi-0/+12
Document shared_from_cow functions
2021-05-25Document shared_from_cow functionsDeadbeef-0/+12
2021-05-20Weak's type parameter may dangle on dropDavid Tolnay-1/+1
2021-05-05alloc: Add unstable Cfg feature `no-global_oom_handling`John Ericson-4/+34
For certain sorts of systems, programming, it's deemed essential that all allocation failures be explicitly handled where they occur. For example, see Linus Torvald's opinion in [1]. Merely not calling global panic handlers, or always `try_reserving` first (for vectors), is not deemed good enough, because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc`, rolling their own allocation abstractions. But this would, in my opinion be a real shame. `alloc` has a few `try_*` methods already, and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature, but there are currently uncertainties around how std library crate's Cargo features may or not be stable, so to avoid any risk of stabilizing by mistake we are going with a more low-level "raw cfg" token, which cannot be interacted with via Cargo alone. Note also that since there is no notion of "default cfg tokens" outside of Cargo features, we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility), but it doesn't matter for raw cfg tokens which are not intended to be "constraint solved" by Cargo or anything else. To support this use-case we create a new feature, "global-oom-handling", on by default, and put the global OOM handler infra and everything else it that depends on it behind it. By default, nothing is changed, but users concerned about global handling can make sure it is disabled, and be confident that all OOM handling is local and explicit. For this first iteration, non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_*` allocation methods, but are kept anyways since they can be oom-safely created "from parts", and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/
2021-03-31panic early when TrustedLen indicates a length > usize::MAXThe8472-2/+5
2021-02-12Add docs for shared_from_slice From implsMichael Howell-0/+49
The advantage of making these docs is mostly in pointing out that these functions all make new allocations and copy/clone/move the source into them. These docs are on the function, and not the `impl` block, to avoid showing the "[+] show undocumented items" button. CC #51430
2021-01-31Rollup merge of #79285 - yoshuawuyts:stabilize-arc_mutate_strong_count, ↵Jonas Schievink-11/+7
r=m-ou-se Stabilize Arc::{increment,decrement}_strong_count Tracking issue: https://github.com/rust-lang/rust/issues/71983 Stabilizes `Arc::{incr,decr}_strong_count`, enabling unsafely incrementing an decrementing the Arc strong count directly with fewer gotchas. This API was first introduced on nightly six months ago, and has not seen any changes since. The initial PR showed two existing pieces of code that would benefit from this API, and included a change inside the stdlib to use this. Given the small surface area, predictable use, and no changes since introduction, I'd like to propose we stabilize this. closes https://github.com/rust-lang/rust/issues/71983 r? `@Mark-Simulacrum` ## Links * [Initial implementation](https://github.com/rust-lang/rust/pull/70733) * [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)
2021-01-30Bump stable version of arc_mutate_strong_countMara Bos-2/+2
2021-01-29rename raw_const/mut -> const/mut_addr_of, and stabilize themRalf Jung-3/+3
2021-01-16Rollup merge of #80764 - CAD97:weak-unsized-as-ptr-again, r=RalfJungMara Bos-46/+34
Re-stabilize Weak::as_ptr and friends for unsized T As per [T-lang consensus](https://hackmd.io/7r3_is6uTz-163fsOV8Vfg), this uses a branch to handle the dangling case. The discussed optimization of only doing the branch in the T: ?Sized case is left for a followup patch, as doing so is not trivial (as it requires specialization) and not _obviously_ better (as it requires using `wrapping_offset` rather than `offset` more). <details><summary>Basically said optimization</summary> Specialize on `T: Sized`: ```rust fn as_ptr(&self) -> *const T { if [ T is Sized ] || !is_dangling(ptr) { (ptr as *mut T).set_ptr_value( (ptr as *mut u8).wrapping_offset(data_offset) ) } else { ptr::null() } } fn from_raw(*const T) -> Self { if [ T is Sized ] || !ptr.is_null() { let ptr = (ptr as *mut RcBox).set_ptr_value( (ptr as *mut u8).wrapping_offset(-data_offset) ); Weak { ptr } } else { Weak::new() } } ``` (but with more `set_ptr_value` to avoid `Sized` restrictions and maintain metadata.) Written in this fashion, this is not a correctness-critical specialization (i.e. so long as `[ T is Sized ]` is false for unsized `T`, it can be `rand()` for sized `T` without breaking correctness), but it's still touchy, so I'd rather do it in another PR with separate review. --- </details> This effectively reverts #80422 and re-establishes #74160. T-libs [previously signed off](https://github.com/rust-lang/rust/pull/74160#issuecomment-660539373) on this stable API change in #74160.
2021-01-13Apply suggestions from code reviewChristopher Durham-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2021-01-12move WriteCloneIntoRaw into alloc::allocJosh Stone-2/+4
2021-01-11Move directly when Rc/Arc::make_mut splits from WeakJosh Stone-9/+6
When only other `Weak` references remain, we can directly move the data into the new unique allocation as a plain memory copy.
2021-01-11Specialize Rc/Arc::make_mut clones to try to avoid localsJosh Stone-3/+9
As we did with `Box`, we can allocate an uninitialized `Rc` or `Arc` beforehand, giving the optimizer a chance to skip the local value for regular clones, or avoid any local altogether for `T: Copy`.
2021-01-10Weak::into_raw shouldn't translate sentinel valueCAD97-12/+9
2021-01-09Provide reasoning for rc data_offset safetyCAD97-4/+6
2021-01-07Replace set_data_ptr with pointer::set_ptr_valueCAD97-16/+2
2021-01-07Reclarify Weak<->raw pointer safety commentsCAD97-2/+2
2021-01-07Remove "pointer describes" terminologyCAD97-5/+4
2021-01-07Tighten/clarify documentation of rc data_offsetCAD97-5/+2
2021-01-06Re-stabilize Weak::as_ptr &friends for unsized TCAD97-17/+24
As per T-lang consensus, this uses a branch to handle the dangling case. The discussed optimization of only doing the branch in the T: ?Sized case is left for a followup patch, as doing so is not trivial (as it requires specialization for correctness, not just optimization).
2021-01-01Auto merge of #80310 - Manishearth:box-try-alloc, r=kennytmbors-2/+115
Add fallible Box, Arc, and Rc allocator APIs cc https://github.com/rust-lang/rust/issues/48043 It was suggested in https://github.com/rust-lang/rust/issues/48043#issuecomment-748008486 that `Box::try_*` follows the spirit of RFC 2116. This PR is an attempt to add the relevant APIs, tied to the same feature gate. Happy to make any changes or turn this into an RFC if necessary. cc `@rust-lang/wg-allocators`
2020-12-31More inline, doc fixesManish Goregaokar-1/+1
2020-12-31Make [A]Rc::allocate_for_layout() use try_allocate_for_layout()Manish Goregaokar-11/+2
2020-12-31Add fallible Arc APIs (`Arc::try_new_*`)Manish Goregaokar-0/+122
2020-12-29Do not create dangling &T in Weak<T>::dropCAD97-1/+1
2020-12-28Rollup merge of #80398 - CAD97:fix-80365, r=dtolnayMara Bos-2/+2
Use raw version of align_of in rc data_offset This was missed in #73845 when switching to use the raw operators. Fixes #80365
2020-12-28de-stabilize unsized raw ptr methods for WeakRalf Jung-1/+3
2020-12-26Use raw version of align_of in rc data_offsetCAD97-2/+2
This was missed in #73845 when switching to use the raw operators. Fixes #80365
2020-12-18Stabilize Arc::{incr,decr}_strong_countYoshua Wuyts-11/+7
2020-12-04 Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`Tim Diekmann-8/+8
2020-10-28Don't say you "should" use fully qualified syntaxCamelid-5/+8
That recommendation was removed last year; there isn't a particular style that is officially recommended anymore.
2020-10-28Explain fully qualified syntax for `Rc` and `Arc`Camelid-2/+14
2020-10-25Merge remote-tracking branch 'upstream/master' into box-allocTim Diekmann-0/+2
2020-10-23Add a spin loop hint for Arc::downgradeNicolas Nattis-0/+2
2020-10-07Support custom allocators in `Box`Tim Diekmann-2/+2
Remove `Box::leak_with_alloc` Add leak-test for box with allocator Rename `AllocErr` to `AllocError` in leak-test Add `Box::alloc` and adjust examples to use the new API
2020-10-03Auto merge of #74160 - CAD97:weak-as-unsized-ptr, r=RalfJungbors-20/+21
Allow Weak::as_ptr and friends for unsized T Relaxes `impl<T> Weak<T>` to `impl<T: ?Sized> Weak<T>` for the methods `rc::Weak::as_ptr`, `into_raw`, and `from_raw`. Follow-up to #73845, which did most of the impl work to make these functions work for `T: ?Sized`. We still have to adjust the implementation of `Weak::from_raw` here, however, because I missed a use of `ptr.is_null()` previously. This check was necessary when `into`/`from_raw` were first implemented, as `into_raw` returned `ptr::null()` for dangling weak. However, we now just (wrapping) offset dangling weaks' pointers the same as nondangling weak, so the null check is no longer necessary (or even hit). (I can submit just 17a928f as a separate PR if desired.) As a nice side effect, moves the `fn is_dangling` definition closer to `Weak::new`, which creates the dangling weak. This technically stabilizes that "something like `align_of_val_raw`" is possible to do. However, I believe the part of the functionality required by these methods here -- specifically, getting the alignment of a pointee from a pointer where it may be dangling iff the pointee is `Sized` -- is uncontroversial enough to stabilize these methods without a way to implement them on stable Rust. r? `@RalfJung,` who reviewed #73845. ATTN: This changes (relaxes) the (input) generic bounds on stable fn!
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 02:59:26 +0000