2017-06-13 17:52:59 -05:00
|
|
|
|
//! # The Rust core allocation and collections library
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
2017-06-13 17:52:59 -05:00
|
|
|
|
//! This library provides smart pointers and collections for managing
|
|
|
|
|
//! heap-allocated values.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
2018-06-23 14:48:56 -05:00
|
|
|
|
//! This library, like libcore, normally doesn’t 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 they’d use this crate instead.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
2014-07-10 16:19:17 -05:00
|
|
|
|
//! ## Boxed values
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
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.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
2015-05-08 10:12:29 -05:00
|
|
|
|
//! 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.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
|
|
|
|
//! ## 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.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
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.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
|
|
|
|
//! ## 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.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//!
|
2017-01-28 16:16:16 -06:00
|
|
|
|
//! This type allows for shared access to the contained data, and is often
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//! 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
|
2018-01-12 15:41:25 -06:00
|
|
|
|
//! 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).
|
|
|
|
|
//!
|
2014-05-13 18:10:05 -05:00
|
|
|
|
//! ## Heap interfaces
|
|
|
|
|
//!
|
2018-04-03 07:41:15 -05:00
|
|
|
|
//! The [`alloc`](alloc/index.html) module defines the low-level interface to the
|
2014-10-24 16:34:57 -05:00
|
|
|
|
//! 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
|
2014-05-13 18:10:05 -05:00
|
|
|
|
|
2015-06-25 12:07:01 -05:00
|
|
|
|
#![allow(unused_attributes)]
|
2019-04-03 12:50:28 -05:00
|
|
|
|
#![stable(feature = "alloc", since = "1.36.0")]
|
2019-12-22 16:42:04 -06:00
|
|
|
|
#![doc(
|
2020-01-30 15:14:39 -06:00
|
|
|
|
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)))
|
|
|
|
|
)]
|
2014-05-13 18:10:05 -05:00
|
|
|
|
#![no_std]
|
2015-12-11 15:07:11 -06:00
|
|
|
|
#![needs_allocator]
|
2018-12-21 04:22:18 -06:00
|
|
|
|
#![warn(deprecated_in_future)]
|
2019-04-15 09:34:08 -05:00
|
|
|
|
#![warn(missing_docs)]
|
2019-01-28 03:49:11 -06:00
|
|
|
|
#![warn(missing_debug_implementations)]
|
2019-04-14 03:16:23 -05:00
|
|
|
|
#![allow(explicit_outlives_requirements)]
|
2020-05-28 16:27:00 -05:00
|
|
|
|
#![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))]
|
2020-09-18 02:35:37 -05:00
|
|
|
|
#![cfg_attr(test, feature(new_uninit))]
|
2018-03-28 15:37:37 -05:00
|
|
|
|
#![feature(allocator_api)]
|
2020-05-18 16:14:55 -05:00
|
|
|
|
#![feature(array_chunks)]
|
2020-10-28 05:58:06 -05:00
|
|
|
|
#![feature(array_methods)]
|
2020-08-13 14:09:14 -05:00
|
|
|
|
#![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)]
|
2020-11-13 11:24:26 -06:00
|
|
|
|
#![feature(async_stream)]
|
2017-06-13 17:52:59 -05:00
|
|
|
|
#![feature(box_patterns)]
|
2015-06-09 13:18:03 -05:00
|
|
|
|
#![feature(box_syntax)]
|
2020-03-19 19:00:00 -05:00
|
|
|
|
#![feature(cfg_sanitize)]
|
2016-10-30 22:14:05 -05:00
|
|
|
|
#![feature(cfg_target_has_atomic)]
|
2015-06-09 13:18:03 -05:00
|
|
|
|
#![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)]
|
2020-09-17 13:02:56 -05:00
|
|
|
|
#![feature(const_cow_is_borrowed)]
|
2020-11-18 11:19:38 -06:00
|
|
|
|
#![feature(destructuring_assignment)]
|
2018-10-03 22:40:21 -05:00
|
|
|
|
#![feature(dispatch_from_dyn)]
|
2015-06-09 13:18:03 -05:00
|
|
|
|
#![feature(core_intrinsics)]
|
2016-12-28 16:47:10 -06:00
|
|
|
|
#![feature(dropck_eyepatch)]
|
2017-06-13 17:52:59 -05:00
|
|
|
|
#![feature(exact_size_is_empty)]
|
2020-08-14 07:50:30 -05:00
|
|
|
|
#![feature(exclusive_range_pattern)]
|
2020-05-12 22:09:55 -05:00
|
|
|
|
#![feature(extend_one)]
|
2017-06-13 17:52:59 -05:00
|
|
|
|
#![feature(fmt_internals)]
|
2019-02-01 06:31:24 -06:00
|
|
|
|
#![feature(fn_traits)]
|
2015-03-30 16:52:00 -05:00
|
|
|
|
#![feature(fundamental)]
|
2019-10-11 13:43:25 -05:00
|
|
|
|
#![feature(inplace_iteration)]
|
2020-12-19 07:23:59 -06:00
|
|
|
|
// 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)]
|
2020-06-28 13:24:09 -05:00
|
|
|
|
#![feature(layout_for_ptr)]
|
2020-04-22 14:45:35 -05:00
|
|
|
|
#![feature(negative_impls)]
|
2019-12-20 13:28:10 -06:00
|
|
|
|
#![feature(never_type)]
|
2018-09-26 16:26:46 -05:00
|
|
|
|
#![feature(nll)]
|
2020-08-04 11:03:34 -05:00
|
|
|
|
#![feature(nonnull_slice_from_raw_parts)]
|
2020-12-30 07:04:59 -06:00
|
|
|
|
#![feature(auto_traits)]
|
2021-01-29 09:21:12 -06:00
|
|
|
|
#![feature(option_result_unwrap_unchecked)]
|
2017-06-13 17:52:59 -05:00
|
|
|
|
#![feature(pattern)]
|
2017-12-22 12:29:16 -06:00
|
|
|
|
#![feature(ptr_internals)]
|
2017-08-22 16:36:49 -05:00
|
|
|
|
#![feature(rustc_attrs)]
|
Stabilize `Rc`, `Arc` and `Pin` as method receivers
This lets you write methods using `self: Rc<Self>`, `self: Arc<Self>`, `self: Pin<&mut Self>`, `self: Pin<Box<Self>`, and other combinations involving `Pin` and another stdlib receiver type, without needing the `arbitrary_self_types`. Other user-created receiver types can be used, but they still require the feature flag to use.
This is implemented by introducing a new trait, `Receiver`, which the method receiver's type must implement if the `arbitrary_self_types` feature is not enabled. To keep composed receiver types such as `&Arc<Self>` unstable, the receiver type is also required to implement `Deref<Target=Self>` when the feature flag is not enabled.
This lets you use `self: Rc<Self>` and `self: Arc<Self>` in stable Rust, which was not allowed previously. It was agreed that they would be stabilized in #55786. `self: Pin<&Self>` and other pinned receiver types do not require the `arbitrary_self_types` feature, but they cannot be used on stable because `Pin` still requires the `pin` feature.
2018-11-20 10:50:50 -06:00
|
|
|
|
#![feature(receiver_trait)]
|
2020-04-19 06:34:00 -05:00
|
|
|
|
#![feature(min_specialization)]
|
2021-01-06 15:34:13 -06:00
|
|
|
|
#![feature(set_ptr_value)]
|
2020-08-04 11:03:34 -05:00
|
|
|
|
#![feature(slice_ptr_get)]
|
|
|
|
|
#![feature(slice_ptr_len)]
|
2021-02-01 20:20:44 -06:00
|
|
|
|
#![feature(slice_range)]
|
2015-06-09 13:18:03 -05:00
|
|
|
|
#![feature(staged_api)]
|
2017-06-13 17:52:59 -05:00
|
|
|
|
#![feature(str_internals)]
|
|
|
|
|
#![feature(trusted_len)]
|
2015-01-26 13:39:58 -06:00
|
|
|
|
#![feature(unboxed_closures)]
|
2018-04-06 07:23:00 -05:00
|
|
|
|
#![feature(unicode_internals)]
|
2015-06-09 13:18:03 -05:00
|
|
|
|
#![feature(unsize)]
|
2020-11-19 14:01:48 -06:00
|
|
|
|
#![feature(unsized_fn_params)]
|
2017-07-17 11:32:08 -05:00
|
|
|
|
#![feature(allocator_internals)]
|
2018-09-16 16:32:16 -05:00
|
|
|
|
#![feature(slice_partition_dedup)]
|
2020-09-09 11:38:10 -05:00
|
|
|
|
#![feature(maybe_uninit_extra, maybe_uninit_slice, maybe_uninit_uninit_array)]
|
2018-10-25 17:48:27 -05:00
|
|
|
|
#![feature(alloc_layout_extra)]
|
2020-08-21 16:53:13 -05:00
|
|
|
|
#![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)]
|
2019-07-31 14:00:35 -05:00
|
|
|
|
#![feature(associated_type_bounds)]
|
2020-12-10 03:16:29 -06:00
|
|
|
|
#![feature(slice_group_by)]
|
2021-01-16 09:32:51 -06:00
|
|
|
|
#![feature(decl_macro)]
|
2021-05-29 02:36:30 -05:00
|
|
|
|
#![feature(bindings_after_at)]
|
2014-05-13 18:10:05 -05:00
|
|
|
|
// 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;
|
|
|
|
|
|
2014-05-13 18:10:05 -05:00
|
|
|
|
// Heaps provided for low-level allocation strategies
|
|
|
|
|
|
2018-04-03 07:41:15 -05:00
|
|
|
|
pub mod alloc;
|
|
|
|
|
|
2014-05-13 18:10:05 -05:00
|
|
|
|
// Primitive types using the heaps above
|
|
|
|
|
|
2015-02-17 14:41:32 -06:00
|
|
|
|
// Need to conditionally define the mod from `boxed.rs` to avoid
|
|
|
|
|
// duplicating the lang-items when building in test cfg; but also need
|
2018-02-18 11:39:40 -06:00
|
|
|
|
// to allow code to have `use boxed::Box;` declarations.
|
2014-05-13 18:10:05 -05:00
|
|
|
|
#[cfg(not(test))]
|
2014-07-10 16:19:17 -05:00
|
|
|
|
pub mod boxed;
|
2015-01-20 14:57:56 -06:00
|
|
|
|
#[cfg(test)]
|
2015-09-23 17:00:54 -05:00
|
|
|
|
mod boxed {
|
2018-02-18 11:39:40 -06:00
|
|
|
|
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)]
|
2019-12-21 05:16:18 -06:00
|
|
|
|
#[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;
|
|
|
|
|
}
|