rust/library/alloc/src/lib.rs

195 lines
6.4 KiB
Rust
Raw Normal View History

2017-06-13 17:52:59 -05:00
//! # The Rust core allocation and collections library
//!
2017-06-13 17:52:59 -05:00
//! This library provides smart pointers and collections for managing
//! heap-allocated values.
//!
//! This library, like libcore, normally doesnt need to be used directly
//! since its contents are re-exported in the [`std` crate](../std/index.html).
//! Crates that use the `#![no_std]` attribute however will typically
//! not depend on `std`, so theyd use this crate instead.
//!
//! ## Boxed values
//!
2019-07-07 10:31:50 -05:00
//! The [`Box`] type is a smart pointer type. There can only be one owner of a
//! [`Box`], and the owner can decide to mutate the contents, which live on the
//! heap.
//!
//! This type can be sent among threads efficiently as the size of a `Box` value
2014-08-04 05:48:39 -05:00
//! is the same as that of a pointer. Tree-like data structures are often built
//! with boxes because each node often has only one owner, the parent.
//!
//! ## Reference counted pointers
//!
2019-07-07 10:31:50 -05:00
//! The [`Rc`] type is a non-threadsafe reference-counted pointer type intended
//! for sharing memory within a thread. An [`Rc`] pointer wraps a type, `T`, and
//! only allows access to `&T`, a shared reference.
//!
2019-07-07 10:31:50 -05:00
//! This type is useful when inherited mutability (such as using [`Box`]) is too
//! constraining for an application, and is often paired with the [`Cell`] or
//! [`RefCell`] types in order to allow mutation.
//!
//! ## Atomically reference counted pointers
//!
2019-07-07 10:31:50 -05:00
//! The [`Arc`] type is the threadsafe equivalent of the [`Rc`] type. It
//! provides all the same functionality of [`Rc`], except it requires that the
//! contained type `T` is shareable. Additionally, [`Arc<T>`][`Arc`] is itself
//! sendable while [`Rc<T>`][`Rc`] is not.
//!
2017-01-28 16:16:16 -06:00
//! This type allows for shared access to the contained data, and is often
//! paired with synchronization primitives such as mutexes to allow mutation of
//! shared resources.
//!
2017-06-13 17:52:59 -05:00
//! ## Collections
//!
//! Implementations of the most common general purpose data structures are
//! defined in this library. They are re-exported through the
2017-06-13 17:52:59 -05:00
//! [standard collections library](../std/collections/index.html).
//!
//! ## Heap interfaces
//!
//! The [`alloc`](alloc/index.html) module defines the low-level interface to the
//! default global allocator. It is not compatible with the libc allocator API.
2019-07-07 10:31:50 -05:00
//!
2020-08-20 16:43:46 -05:00
//! [`Arc`]: sync
//! [`Box`]: boxed
//! [`Cell`]: core::cell
//! [`Rc`]: rc
//! [`RefCell`]: core::cell
#![allow(unused_attributes)]
#![stable(feature = "alloc", since = "1.36.0")]
2019-12-22 16:42:04 -06:00
#![doc(
html_playground_url = "https://play.rust-lang.org/",
2019-12-22 16:42:04 -06:00
issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/",
test(no_crate_inject, attr(allow(unused_variables), deny(warnings)))
)]
#![no_std]
#![needs_allocator]
2018-12-21 04:22:18 -06:00
#![warn(deprecated_in_future)]
#![warn(missing_docs)]
#![warn(missing_debug_implementations)]
2019-04-14 03:16:23 -05:00
#![allow(explicit_outlives_requirements)]
#![deny(unsafe_op_in_unsafe_fn)]
2020-11-19 14:01:48 -06:00
#![feature(rustc_allow_const_fn_unstable)]
2017-07-07 17:31:03 -05:00
#![cfg_attr(not(test), feature(generator_trait))]
2018-07-25 08:27:27 -05:00
#![cfg_attr(test, feature(test))]
#![cfg_attr(test, feature(new_uninit))]
#![feature(allocator_api)]
2020-05-18 16:14:55 -05:00
#![feature(array_chunks)]
#![feature(array_methods)]
#![feature(array_windows)]
2017-06-13 17:52:59 -05:00
#![feature(allow_internal_unstable)]
2018-06-08 15:45:27 -05:00
#![feature(arbitrary_self_types)]
#![feature(async_stream)]
2017-06-13 17:52:59 -05:00
#![feature(box_patterns)]
#![feature(box_syntax)]
#![feature(cfg_sanitize)]
#![feature(cfg_target_has_atomic)]
#![feature(coerce_unsized)]
alloc: Add unstable Cfg feature `no-global_oom_handling` 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-04-16 19:18:04 -05:00
#![cfg_attr(not(no_global_oom_handling), feature(const_btree_new))]
2021-05-06 06:36:07 -05:00
#![feature(const_fn_trait_bound)]
2019-10-05 17:23:37 -05:00
#![feature(cow_is_borrowed)]
#![feature(const_cow_is_borrowed)]
#![feature(destructuring_assignment)]
#![feature(dispatch_from_dyn)]
#![feature(core_intrinsics)]
#![feature(dropck_eyepatch)]
2017-06-13 17:52:59 -05:00
#![feature(exact_size_is_empty)]
#![feature(exclusive_range_pattern)]
#![feature(extend_one)]
2017-06-13 17:52:59 -05:00
#![feature(fmt_internals)]
#![feature(fn_traits)]
#![feature(fundamental)]
#![feature(inplace_iteration)]
// Technically, this is a bug in rustdoc: rustdoc sees the documentation on `#[lang = slice_alloc]`
// blocks is for `&[T]`, which also has documentation using this feature in `core`, and gets mad
// that the feature-gate isn't enabled. Ideally, it wouldn't check for the feature gate for docs
// from other crates, but since this can only appear for lang items, it doesn't seem worth fixing.
#![feature(intra_doc_pointers)]
2021-03-08 17:32:41 -06:00
#![feature(iter_zip)]
2015-04-27 16:10:49 -05:00
#![feature(lang_items)]
#![feature(layout_for_ptr)]
2020-04-22 14:45:35 -05:00
#![feature(negative_impls)]
#![feature(never_type)]
#![feature(nll)]
#![feature(nonnull_slice_from_raw_parts)]
2020-12-30 07:04:59 -06:00
#![feature(auto_traits)]
#![feature(option_result_unwrap_unchecked)]
2017-06-13 17:52:59 -05:00
#![feature(pattern)]
#![feature(ptr_internals)]
#![feature(rustc_attrs)]
#![feature(receiver_trait)]
#![feature(min_specialization)]
#![feature(set_ptr_value)]
#![feature(slice_ptr_get)]
#![feature(slice_ptr_len)]
#![feature(slice_range)]
#![feature(staged_api)]
2017-06-13 17:52:59 -05:00
#![feature(str_internals)]
#![feature(trusted_len)]
#![feature(unboxed_closures)]
#![feature(unicode_internals)]
#![feature(unsize)]
2020-11-19 14:01:48 -06:00
#![feature(unsized_fn_params)]
#![feature(allocator_internals)]
#![feature(slice_partition_dedup)]
#![feature(maybe_uninit_extra, maybe_uninit_slice, maybe_uninit_uninit_array)]
#![feature(alloc_layout_extra)]
#![feature(trusted_random_access)]
2021-05-10 00:05:02 -05:00
#![cfg_attr(bootstrap, feature(try_trait))]
#![cfg_attr(not(bootstrap), feature(try_trait_v2))]
2021-03-26 15:10:21 -05:00
#![feature(min_type_alias_impl_trait)]
#![feature(associated_type_bounds)]
#![feature(slice_group_by)]
2021-01-16 09:32:51 -06:00
#![feature(decl_macro)]
#![feature(bindings_after_at)]
// Allow testing this library
2015-09-23 17:00:54 -05:00
#[cfg(test)]
#[macro_use]
extern crate std;
2017-06-13 17:52:59 -05:00
#[cfg(test)]
extern crate test;
2016-10-15 10:32:14 -05:00
// Module with internal macros used by other modules (needs to be included before other modules).
#[macro_use]
mod macros;
// Heaps provided for low-level allocation strategies
pub mod alloc;
// Primitive types using the heaps above
// Need to conditionally define the mod from `boxed.rs` to avoid
// duplicating the lang-items when building in test cfg; but also need
// to allow code to have `use boxed::Box;` declarations.
#[cfg(not(test))]
pub mod boxed;
#[cfg(test)]
2015-09-23 17:00:54 -05:00
mod boxed {
pub use std::boxed::Box;
2015-09-23 17:00:54 -05:00
}
2017-06-13 17:52:59 -05:00
pub mod borrow;
2019-12-22 16:42:04 -06:00
pub mod collections;
2017-06-13 17:52:59 -05:00
pub mod fmt;
2019-12-22 16:42:04 -06:00
pub mod prelude;
pub mod raw_vec;
pub mod rc;
2017-06-13 17:52:59 -05:00
pub mod slice;
pub mod str;
pub mod string;
2019-12-22 16:42:04 -06:00
#[cfg(target_has_atomic = "ptr")]
pub mod sync;
alloc: Add unstable Cfg feature `no-global_oom_handling` 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-04-16 19:18:04 -05:00
#[cfg(all(not(no_global_oom_handling), target_has_atomic = "ptr"))]
Add Wake trait for safe construction of Wakers. Currently, constructing a waker requires calling the unsafe `Waker::from_raw` API. This API requires the user to manually construct a vtable for the waker themself - which is both cumbersome and very error prone. This API would provide an ergonomic, straightforward and guaranteed memory-safe way of constructing a waker. It has been our longstanding intention that the `Waker` type essentially function as an `Arc<dyn Wake>`, with a `Wake` trait as defined here. Two considerations prevented the original API from being shipped as simply an `Arc<dyn Wake>`: - We want to support futures on embedded systems, which may not have an allocator, and in optimized executors for which this API may not be best-suited. Therefore, we have always explicitly supported the maximally-flexible (but also memory-unsafe) `RawWaker` API, and `Waker` has always lived in libcore. - Because `Waker` lives in libcore and `Arc` lives in liballoc, it has not been feasible to provide a constructor for `Waker` from `Arc<dyn Wake>`. Therefore, the Wake trait was left out of the initial version of the task waker API. However, as Rust 1.41, it is possible under the more flexible orphan rules to implement `From<Arc<W>> for Waker where W: Wake` in liballoc. Therefore, we can now define this constructor even though `Waker` lives in libcore. This PR adds these APIs: - A `Wake` trait, which contains two methods - A required method `wake`, which is called by `Waker::wake` - A provided method `wake_by_ref`, which is called by `Waker::wake_by_ref` and which implementors can override if they can optimize this use case. - An implementation of `From<Arc<W>> for Waker where W: Wake + Send + Sync + 'static` - A similar implementation of `From<Arc<W>> for RawWaker`.
2020-01-31 07:26:24 -06:00
pub mod task;
2019-12-22 16:42:04 -06:00
#[cfg(test)]
mod tests;
2017-06-13 17:52:59 -05:00
pub mod vec;
2019-09-01 06:10:50 -05:00
#[doc(hidden)]
#[unstable(feature = "liballoc_internals", issue = "none", reason = "implementation detail")]
2019-09-01 06:10:50 -05:00
pub mod __export {
pub use core::format_args;
}