about summary refs log tree commit diff
path: root/library/alloc/src/boxed.rs
AgeCommit message (Collapse)AuthorLines
2021-10-09Remove unnecessary hyphenTim McNamara-1/+1
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
2021-10-09Simplify wordingTim McNamara-4/+4
Co-authored-by: Josh Triplett <josh@joshtriplett.org> Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
2021-10-08Add documentation to boxed conversionsTim McNamara-0/+41
Among other changes, documents whether allocations are necessary to complete the type conversion. Part of #51430 Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com> Co-authored-by: Joshua Nelson <github@jyn.dev>
2021-09-17Fix missing `no_global_oom_handling` cfg-gatingGary Guo-0/+2
2021-08-05add Box::try_new_uninit_slice for symmetryThe8472-0/+33
2021-08-05remove cfg gate on `use RawVec` since it is now also used in fallible codeThe8472-1/+0
2021-08-05add Box::try_new_zeroed_slice()The8472-0/+32
Currently there is no API that allows fallible zero-allocation of a Vec. Vec.try_reserve is not appropriate for this job since it doesn't know whether it should zero or arbitrary uninitialized memory is fine. Since Box currently holds most of the zeroing/uninit/slice allocation APIs it's the best place to add yet another entry into this feature matrix.
2021-06-30Remove alloc/malloc/calloc/realloc doc aliasesAmanieu d'Antras-3/+0
2021-06-12Remove "generic type" in boxed.rsDeadbeef-1/+1
2021-05-05alloc: Add unstable Cfg feature `no-global_oom_handling`John Ericson-2/+33
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-05-02Change 'NULL' to 'null'Brent Kerby-1/+1
2021-04-10fix incorrect from_raw_in doctestRalf Jung-1/+1
2021-02-12Remove unnecessary lint allow attrs on exampleMikail Bagishov-2/+0
2021-02-10Rollup merge of #80438 - crlf0710:box_into_inner, r=m-ou-seYuki Okushi-0/+17
Add `Box::into_inner`. This adds a `Box::into_inner` method to the `Box` type. <del>I actually suggest deprecating the compiler magic of `*b` if this gets stablized in the future.</del> r? `@m-ou-se`
2021-02-09Add `Box::into_inner`.Charles Lew-0/+17
2021-02-06Prefer match intead of combinators to make some Box function inlineableLzu Tao-2/+12
2021-01-31Rollup merge of #80945 - sdroege:downcast-send-sync, r=m-ou-seJonas Schievink-0/+33
Add Box::downcast() for dyn Any + Send + Sync Looks like a plain omission, but unfortunately I just needed that in my code :)
2021-01-30Rollup merge of #79023 - yoshuawuyts:stream, r=KodrAusYuki Okushi-0/+14
Add `core::stream::Stream` [[Tracking issue: #79024](https://github.com/rust-lang/rust/issues/79024)] This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with [RFC2996](https://github.com/rust-lang/rfcs/pull/2996). The RFC hasn't been merged yet, but as requested by the libs team in https://github.com/rust-lang/rfcs/pull/2996#issuecomment-725696389 I'm filing this PR to get the ball rolling. ## Documentatation The docs in this PR have been adapted from [`std::iter`](https://doc.rust-lang.org/std/iter/index.html), [`async_std::stream`](https://docs.rs/async-std/1.7.0/async_std/stream/index.html), and [`futures::stream::Stream`](https://docs.rs/futures/0.3.8/futures/stream/trait.Stream.html). Once this PR lands my plan is to follow this up with PRs to add helper methods such as `stream::repeat` which can be used to document more of the concepts that are currently missing. That will allow us to cover concepts such as "infinite streams" and "laziness" in more depth. ## Feature gate The feature gate for `Stream` is `stream_trait`. This matches the `#[lang = "future_trait"]` attribute name. The intention is that only the APIs defined in RFC2996 will use this feature gate, with future additions such as `stream::repeat` using their own feature gates. This is so we can ensure a smooth path towards stabilizing the `Stream` trait without needing to stabilize all the APIs in `core::stream` at once. But also don't start expanding the API until _after_ stabilization, as was the case with `std::future`. __edit:__ the feature gate has been changed to `async_stream` to match the feature gate proposed in the RFC. ## Conclusion This PR introduces `core::stream::{Stream, Next}` and re-exports it from `std` as `std::stream::{Stream, Next}`. Landing `Stream` in the stdlib has been a mult-year process; and it's incredibly exciting for this to finally happen! --- r? `````@KodrAus````` cc/ `````@rust-lang/wg-async-foundations````` `````@rust-lang/libs`````
2021-01-22Add doc aliases for memory allocationsYoshua Wuyts-2/+5
- Vec::with_capacity / Box::new -> alloc + malloc - Box::new_zeroed -> calloc - Vec::{reserve,reserve_exact,try_reserve_exact,shrink_to_fit,shrink_to} -> realloc
2021-01-22Add `core::stream::Stream`Yoshua Wuyts-0/+14
This patch adds the `core::stream` submodule and implements `core::stream::Stream` in accordance with RFC2996. Add feedback from @camelid
2021-01-12move WriteCloneIntoRaw into alloc::allocJosh Stone-23/+1
2021-01-12Add Box::downcast() for dyn Any + Send + SyncSebastian Dröge-0/+33
2021-01-11Specialize Box clones to try to avoid localsJosh Stone-2/+28
For generic `T: Clone`, we can allocate an uninitialized box beforehand, which gives the optimizer a chance to create the clone directly in the heap. For `T: Copy`, we can go further and do a simple memory copy, regardless of optimization level.
2021-01-02Auto merge of #77832 - camelid:remove-manual-link-resolves, r=jyn514bors-2/+0
Remove many unnecessary manual link resolves from library Now that #76934 has merged, we can remove a lot of these! E.g, this is no longer necessary: [`Vec<T>`]: Vec cc `@jyn514`
2020-12-31Remove many unnecessary manual link resolves from libraryCamelid-2/+0
Now that #76934 has merged, we can remove a lot of these! E.g, this is no longer necessary: [`Vec<T>`]: Vec
2020-12-31More inline, doc fixesManish Goregaokar-1/+2
2020-12-31Reuse Box::try_new_*_in() in Box::new_*_in()Manish Goregaokar-5/+2
2020-12-31Add fallible box APIs (`Box::try_new_*`)Manish Goregaokar-1/+73
2020-12-31Add fallible box allocator APIs (`Box::try_new_*_in()`)Manish Goregaokar-1/+85
2020-12-04 Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`Tim Diekmann-66/+67
2020-11-28Require allocator to be static for boxed `Pin`-APITim Diekmann-7/+25
2020-11-21Auto merge of #78461 - TimDiekmann:vec-alloc, r=Amanieubors-2/+3
Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate
2020-11-21Rollup merge of #77844 - RalfJung:zst-box, r=nikomatsakisDylan DPC-0/+11
clarify rules for ZST Boxes LLVM's rules around `getelementptr inbounds` with offset 0 are a bit annoying, and as a consequence we have no choice but say that a `Box<()>` pointing to previously allocated memory that has since been freed is UB. Clarify the docs to reflect this. This is based on conversations on the LLVM mailing list. * Here's my initial mail: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130452.html * The first email of the March part of that thread: https://lists.llvm.org/pipermail/llvm-dev/2019-March/130831.html * First email of the April part: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131693.html The conclusion for me at least was that `getelementptr inbounds` with offset 0 is *not* the identity function, but can sometimes return `poison` even when the input is a regular pointer -- specifically, it returns `poison` when this pointer points into something that LLVM "knows has been deallocated", i.e., a former LLVM-managed allocation. It is however the identity function on pointers obtained by casting integers. Note that there [are formal proposals](https://people.mpi-sws.org/~jung/twinsem/twinsem.pdf) for LLVM semantics where `getelementptr inbounds` with offset 0 isn't quite the identity function but never returns `poison` (it affects the provenance of the pointer but in a way that doesn't matter if this pointer is never used for memory accesses), and indeed this is likely necessary to consistently describe LLVM semantics. But with the informal LLVM LangRef that we have right now, and with LLVM devs insisting otherwise, it seems unwise to rely on this.
2020-11-20reference NonNull::danglingRalf Jung-4/+6
2020-11-18Add support for custom allocators in `Vec`Tim Diekmann-2/+3
2020-10-27fix Box::into_uniqueRalf Jung-7/+2
2020-10-23Rename `Box::alloc` to `Box::alloc_ref`Tim Diekmann-2/+2
2020-10-16Merge branch 'master' into box-allocTim Diekmann-1/+1
2020-10-15Fix typo in documentationstrct-1/+1
2020-10-13explicitly talk about integer literalsRalf Jung-3/+3
2020-10-12clarify rules for ZST BoxesRalf Jung-0/+9
2020-10-07Support custom allocators in `Box`Tim Diekmann-110/+380
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-09-01Use intra-doc links for `MaybeUninit` in `boxed.rs`Joshua Nelson-4/+4
2020-08-22Auto merge of #75171 - amosonn:new_zeroed_slice, r=Amanieubors-0/+23
New zeroed slice Add to #63291 the methods ```rust impl<T> Box<[T]> { pub fn new_zeroed_slice(len: usize) -> Box<[MaybeUninit<T>]> {…} } impl<T> Rc<[T]> { pub fn new_zeroed_slice(len: usize) -> Rc<[MaybeUninit<T>]> {…} } impl<T> Arc<[T]> { pub fn new_zeroed_slice(len: usize) -> Arc<[MaybeUninit<T>]> {…} } ``` as suggested in https://github.com/rust-lang/rust/issues/63291#issuecomment-605511675 . Also optimize `{Rc, Arc}::new_zeroed` to use `alloc_zeroed`, otherwise they are no more efficient than using `new_uninit` and zeroing the memory manually (which was the original implementation).
2020-08-21Use intra-doc-links in `alloc`LeSeulArtichaut-16/+10
2020-08-05Add {Box,Rc,Arc}::new_zeroed_sliceAmos Onn-0/+23
2020-08-04Replace `Memoryblock` with `NonNull<[u8]>`Tim Diekmann-3/+1
2020-08-03Merge branch 'master' into remove-in-place-allocTim Diekmann-45/+1
2020-07-29Remove deprecated unstable `{Box,Rc,Arc}::into_raw_non_null` functionsSimon Sapin-45/+1
FCP: https://github.com/rust-lang/rust/issues/47336#issuecomment-619369613
2020-07-28Remove in-place allocation and revert to separate methods for zeroed allocationsTim Diekmann-7/+4
Fix docs
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 19:46:44 +0000