rust/library/std/src/lib.rs

598 lines
22 KiB
Rust
Raw Normal View History

//! # The Rust Standard Library
//!
//! The Rust Standard Library is the foundation of portable Rust software, a
//! set of minimal and battle-tested shared abstractions for the [broader Rust
//! ecosystem][crates.io]. It offers core types, like [`Vec<T>`] and
//! [`Option<T>`], library-defined [operations on language
//! primitives](#primitives), [standard macros](#macros), [I/O] and
//! [multithreading], among [many other things][other].
//!
2019-02-09 22:16:58 +00:00
//! `std` is available to all Rust crates by default. Therefore, the
//! standard library can be accessed in [`use`] statements through the path
//! `std`, as in [`use std::env`].
//!
//! # How to read this documentation
//!
2015-12-17 18:55:20 +00:00
//! If you already know the name of what you are looking for, the fastest way to
//! find it is to use the <a href="#" onclick="focusSearchBar();">search
//! bar</a> at the top of the page.
//!
//! Otherwise, you may want to jump to one of these useful sections:
//!
//! * [`std::*` modules](#modules)
//! * [Primitive types](#primitives)
//! * [Standard macros](#macros)
//! * [The Rust Prelude]
//!
//! If this is your first time, the documentation for the standard library is
//! written to be casually perused. Clicking on interesting things should
//! generally lead you to interesting places. Still, there are important bits
//! you don't want to miss, so read on for a tour of the standard library and
//! its documentation!
//!
//! Once you are familiar with the contents of the standard library you may
//! begin to find the verbosity of the prose distracting. At this stage in your
2018-04-01 19:06:35 +00:00
//! development you may want to press the `[-]` button near the top of the
//! page to collapse it into a more skimmable view.
//!
2018-04-01 19:06:35 +00:00
//! While you are looking at that `[-]` button also notice the `[src]`
//! button. Rust's API documentation comes with the source code and you are
//! encouraged to read it. The standard library source is generally high
//! quality and a peek behind the curtains is often enlightening.
//!
//! # What is in the standard library documentation?
//!
//! First of all, The Rust Standard Library is divided into a number of focused
//! modules, [all listed further down this page](#modules). These modules are
//! the bedrock upon which all of Rust is forged, and they have mighty names
//! like [`std::slice`] and [`std::cmp`]. Modules' documentation typically
//! includes an overview of the module along with examples, and are a smart
//! place to start familiarizing yourself with the library.
//!
//! Second, implicit methods on [primitive types] are documented here. This can
//! be a source of confusion for two reasons:
//!
//! 1. While primitives are implemented by the compiler, the standard library
//! implements methods directly on the primitive types (and it is the only
//! library that does so), which are [documented in the section on
//! primitives](#primitives).
//! 2. The standard library exports many modules *with the same name as
//! primitive types*. These define additional items related to the primitive
//! type, but not the all-important methods.
//!
//! So for example there is a [page for the primitive type
//! `i32`](primitive::i32) that lists all the methods that can be called on
//! 32-bit integers (very useful), and there is a [page for the module
//! `std::i32`] that documents the constant values [`MIN`] and [`MAX`] (rarely
//! useful).
//!
//! Note the documentation for the primitives [`str`] and [`[T]`][prim@slice] (also
//! called 'slice'). Many method calls on [`String`] and [`Vec<T>`] are actually
//! calls to methods on [`str`] and [`[T]`][prim@slice] respectively, via [deref
//! coercions][deref-coercions].
//!
//! Third, the standard library defines [The Rust Prelude], a small collection
//! of items - mostly traits - that are imported into every module of every
//! crate. The traits in the prelude are pervasive, making the prelude
2015-07-14 00:56:31 +00:00
//! documentation a good entry point to learning about the library.
//!
//! And finally, the standard library exports a number of standard macros, and
//! [lists them on this page](#macros) (technically, not all of the standard
//! macros are defined by the standard library - some are defined by the
//! compiler - but they are documented here the same). Like the prelude, the
//! standard macros are imported by default into all crates.
//!
//! # Contributing changes to the documentation
//!
2017-04-07 20:42:56 +00:00
//! Check out the rust contribution guidelines [here](
//! https://rustc-dev-guide.rust-lang.org/contributing.html#writing-documentation).
2020-07-04 16:41:21 +00:00
//! The source for this documentation can be found on
//! [GitHub](https://github.com/rust-lang/rust).
//! To contribute changes, make sure you read the guidelines first, then submit
//! pull-requests for your suggested changes.
2017-04-07 20:42:56 +00:00
//!
//! Contributions are appreciated! If you see a part of the docs that can be
//! improved, submit a PR, or chat with us first on [Discord][rust-discord]
//! #docs.
//!
//! # A Tour of The Rust Standard Library
//!
//! The rest of this crate documentation is dedicated to pointing out notable
//! features of The Rust Standard Library.
//!
//! ## Containers and collections
//!
//! The [`option`] and [`result`] modules define optional and error-handling
//! types, [`Option<T>`] and [`Result<T, E>`]. The [`iter`] module defines
//! Rust's iterator trait, [`Iterator`], which works with the [`for`] loop to
//! access collections.
//!
//! The standard library exposes three common ways to deal with contiguous
2015-07-14 00:56:31 +00:00
//! regions of memory:
//!
//! * [`Vec<T>`] - A heap-allocated *vector* that is resizable at runtime.
//! * [`[T; N]`][prim@array] - An inline *array* with a fixed size at compile time.
//! * [`[T]`][prim@slice] - A dynamically sized *slice* into any other kind of contiguous
//! storage, whether heap-allocated or not.
2015-07-14 00:56:31 +00:00
//!
//! Slices can only be handled through some kind of *pointer*, and as such come
//! in many flavors such as:
2015-07-14 00:56:31 +00:00
//!
//! * `&[T]` - *shared slice*
//! * `&mut [T]` - *mutable slice*
//! * [`Box<[T]>`][owned slice] - *owned slice*
2015-07-14 17:25:54 +00:00
//!
//! [`str`], a UTF-8 string slice, is a primitive type, and the standard library
//! defines many methods for it. Rust [`str`]s are typically accessed as
//! immutable references: `&str`. Use the owned [`String`] for building and
//! mutating strings.
//!
//! For converting to strings use the [`format!`] macro, and for converting from
//! strings use the [`FromStr`] trait.
//!
//! Data may be shared by placing it in a reference-counted box or the [`Rc`]
//! type, and if further contained in a [`Cell`] or [`RefCell`], may be mutated
//! as well as shared. Likewise, in a concurrent setting it is common to pair an
//! atomically-reference-counted box, [`Arc`], with a [`Mutex`] to get the same
//! effect.
//!
//! The [`collections`] module defines maps, sets, linked lists and other
//! typical collection types, including the common [`HashMap<K, V>`].
//!
//! ## Platform abstractions and I/O
//!
//! Besides basic data types, the standard library is largely concerned with
//! abstracting over differences in common platforms, most notably Windows and
//! Unix derivatives.
//!
//! Common types of I/O, including [files], [TCP], [UDP], are defined in the
//! [`io`], [`fs`], and [`net`] modules.
//!
//! The [`thread`] module contains Rust's threading abstractions. [`sync`]
//! contains further primitive shared memory types, including [`atomic`] and
//! [`mpsc`], which contains the channel types for message passing.
//!
//! [I/O]: io
//! [`MIN`]: i32::MIN
//! [`MAX`]: i32::MAX
//! [page for the module `std::i32`]: crate::i32
//! [TCP]: net::TcpStream
//! [The Rust Prelude]: prelude
//! [UDP]: net::UdpSocket
//! [`Arc`]: sync::Arc
//! [owned slice]: boxed
//! [`Cell`]: cell::Cell
//! [`FromStr`]: str::FromStr
//! [`HashMap<K, V>`]: collections::HashMap
//! [`Mutex`]: sync::Mutex
//! [`Option<T>`]: option::Option
//! [`Rc`]: rc::Rc
//! [`RefCell`]: cell::RefCell
//! [`Result<T, E>`]: result::Result
//! [`Vec<T>`]: vec::Vec
//! [`atomic`]: sync::atomic
2018-11-21 00:49:47 +00:00
//! [`for`]: ../book/ch03-05-control-flow.html#looping-through-a-collection-with-for
2020-08-22 20:29:55 +00:00
//! [`str`]: prim@str
//! [`mpsc`]: sync::mpsc
//! [`std::cmp`]: cmp
//! [`std::slice`]: mod@slice
//! [`use std::env`]: env/index.html
2019-02-24 17:44:59 +00:00
//! [`use`]: ../book/ch07-02-defining-modules-to-control-scope-and-privacy.html
//! [crates.io]: https://crates.io
2018-11-20 23:42:49 +00:00
//! [deref-coercions]: ../book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods
//! [files]: fs::File
//! [multithreading]: thread
//! [other]: #what-is-in-the-standard-library-documentation
2018-11-20 23:42:49 +00:00
//! [primitive types]: ../book/ch03-02-data-types.html
//! [rust-discord]: https://discord.gg/rust-lang
//! [array]: prim@array
//! [slice]: prim@slice
2020-06-01 01:09:25 +00:00
#![cfg_attr(not(feature = "restricted-std"), stable(feature = "rust1", since = "1.0.0"))]
#![cfg_attr(feature = "restricted-std", unstable(feature = "restricted_std", issue = "none"))]
2019-12-22 22:42:04 +00:00
#![doc(
html_root_url = "https://doc.rust-lang.org/nightly/",
html_playground_url = "https://play.rust-lang.org/",
issue_tracker_base_url = "https://github.com/rust-lang/rust/issues/",
test(no_crate_inject, attr(deny(warnings))),
test(attr(allow(dead_code, deprecated, unused_variables, unused_mut)))
)]
// Don't link to std. We are std.
#![no_std]
#![warn(deprecated_in_future)]
2019-04-14 08:16:23 +00:00
#![warn(missing_docs)]
#![warn(missing_debug_implementations)]
2019-02-10 19:23:21 +00:00
#![allow(explicit_outlives_requirements)]
#![allow(unused_lifetimes)]
// Tell the compiler to link to either panic_abort or panic_unwind
#![needs_panic_runtime]
// std may use features in a platform-specific way
#![allow(unused_features)]
2020-11-19 20:01:48 +00:00
#![feature(rustc_allow_const_fn_unstable)]
#![cfg_attr(
test,
feature(internal_output_capture, print_internals, update_panic_count, thread_local_const_init)
)]
2019-12-22 22:42:04 +00:00
#![cfg_attr(
all(target_vendor = "fortanix", target_env = "sgx"),
2020-08-22 18:57:45 +00:00
feature(slice_index_methods, coerce_unsized, sgx_platform)
2019-12-22 22:42:04 +00:00
)]
#![deny(rustc::existing_doc_keyword)]
// std is implemented with unstable features, many of which are internal
// compiler details that will never be stable
// NB: the following list is sorted to minimize merge conflicts.
#![feature(alloc_error_handler)]
#![feature(alloc_layout_extra)]
#![feature(allocator_api)]
#![feature(allocator_internals)]
#![feature(allow_internal_unsafe)]
2015-04-28 23:36:22 +00:00
#![feature(allow_internal_unstable)]
#![feature(async_stream)]
2018-06-08 20:45:27 +00:00
#![feature(arbitrary_self_types)]
#![feature(array_error_internals)]
#![feature(asm)]
2021-03-04 16:55:23 +00:00
#![feature(assert_matches)]
#![feature(associated_type_bounds)]
#![feature(atomic_mut_ptr)]
#![feature(box_syntax)]
#![feature(c_variadic)]
2020-07-10 15:59:25 +00:00
#![feature(cfg_accessible)]
2021-03-26 20:10:21 +00:00
#![feature(cfg_eval)]
#![feature(cfg_target_has_atomic)]
#![feature(cfg_target_thread_local)]
2017-05-27 22:12:16 +00:00
#![feature(char_error_internals)]
2020-05-30 09:53:50 +00:00
#![feature(char_internals)]
#![feature(concat_idents)]
#![feature(const_cstr_unchecked)]
2020-10-07 22:56:26 +00:00
#![feature(const_fn_floating_point_arithmetic)]
#![feature(const_fn_transmute)]
#![feature(const_fn)]
2020-10-07 22:56:26 +00:00
#![feature(const_fn_fn_ptr_basics)]
#![feature(const_io_structs)]
#![feature(const_ip)]
#![feature(const_ipv6)]
#![feature(const_raw_ptr_deref)]
#![feature(const_socketaddr)]
#![feature(const_ipv4)]
#![feature(container_error_extra)]
#![feature(core_intrinsics)]
#![feature(custom_test_frameworks)]
2019-09-21 17:18:41 +00:00
#![feature(decl_macro)]
#![feature(doc_cfg)]
#![feature(doc_keyword)]
#![feature(doc_masked)]
#![cfg_attr(bootstrap, feature(doc_spotlight))]
#![cfg_attr(not(bootstrap), feature(doc_notable_trait))]
#![feature(dropck_eyepatch)]
2019-01-06 13:02:42 +00:00
#![feature(duration_constants)]
#![feature(edition_panic)]
#![feature(exact_size_is_empty)]
#![feature(exhaustive_patterns)]
#![feature(extend_one)]
#![feature(extended_key_value_attributes)]
#![feature(fn_traits)]
#![feature(format_args_nl)]
#![feature(gen_future)]
2018-06-06 22:50:59 +00:00
#![feature(generator_trait)]
#![feature(get_mut_unchecked)]
#![feature(global_asm)]
#![feature(hashmap_internals)]
#![feature(int_error_internals)]
2019-04-22 22:15:43 +00:00
#![feature(int_error_matching)]
#![feature(integer_atomics)]
2020-07-10 15:59:25 +00:00
#![feature(into_future)]
#![feature(intra_doc_pointers)]
2021-03-08 23:32:41 +00:00
#![feature(iter_zip)]
#![feature(lang_items)]
#![feature(linkage)]
#![feature(llvm_asm)]
#![feature(log_syntax)]
2021-03-04 14:57:26 +00:00
#![feature(map_try_insert)]
#![feature(maybe_uninit_extra)]
#![feature(maybe_uninit_ref)]
#![feature(maybe_uninit_slice)]
#![feature(maybe_uninit_uninit_array)]
2020-07-10 15:59:25 +00:00
#![feature(min_specialization)]
#![feature(needs_panic_runtime)]
2020-04-22 19:45:35 +00:00
#![feature(negative_impls)]
#![feature(never_type)]
#![feature(new_uninit)]
2019-02-10 19:25:30 +00:00
#![feature(nll)]
#![feature(nonnull_slice_from_raw_parts)]
#![feature(once_cell)]
2020-12-30 13:04:59 +00:00
#![feature(auto_traits)]
2020-11-21 21:18:04 +00:00
#![cfg_attr(bootstrap, feature(or_patterns))]
#![feature(panic_info_message)]
#![feature(panic_internals)]
#![feature(panic_unwind)]
#![feature(pin_static_ref)]
#![feature(prelude_2021)]
2016-08-22 19:47:38 +00:00
#![feature(prelude_import)]
#![feature(ptr_internals)]
#![feature(raw)]
2020-04-05 15:50:45 +00:00
#![feature(ready_macro)]
#![feature(rustc_attrs)]
#![feature(rustc_private)]
#![feature(shrink_to)]
#![feature(slice_concat_ext)]
2017-12-13 07:02:19 +00:00
#![feature(slice_internals)]
#![feature(slice_ptr_get)]
#![feature(slice_ptr_len)]
#![feature(staged_api)]
#![feature(std_internals)]
#![feature(stdsimd)]
2016-01-05 20:30:14 +00:00
#![feature(stmt_expr_attributes)]
#![feature(str_internals)]
#![feature(test)]
#![feature(thread_local)]
#![feature(thread_local_internals)]
#![feature(toowned_clone_into)]
#![feature(total_cmp)]
#![feature(trace_macros)]
#![feature(try_blocks)]
#![feature(try_reserve)]
#![feature(unboxed_closures)]
#![feature(unsafe_cell_raw_get)]
#![feature(unwind_attributes)]
#![feature(vec_into_raw_parts)]
#![feature(vec_spare_capacity)]
// NB: the above list is sorted to minimize merge conflicts.
#![default_lib_allocator]
// Explicitly import the prelude. The compiler uses this same unstable attribute
// to import the prelude implicitly when building crates that depend on std.
2016-08-22 19:47:38 +00:00
#[prelude_import]
#[allow(unused)]
use prelude::v1::*;
// Access to Bencher, etc.
2019-12-22 22:42:04 +00:00
#[cfg(test)]
extern crate test;
#[allow(unused_imports)] // macros from `alloc` are not used on all platforms
#[macro_use]
extern crate alloc as alloc_crate;
#[doc(masked)]
2019-02-10 19:23:21 +00:00
#[allow(unused_extern_crates)]
2014-06-04 03:09:39 +00:00
extern crate libc;
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
// We always need an unwinder currently for backtraces
#[doc(masked)]
#[allow(unused_extern_crates)]
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-04-08 23:18:40 +00:00
extern crate unwind;
// During testing, this crate is not actually the "real" std library, but rather
// it links to the real std library, which was compiled from this same source
// code. So any lang items std defines are conditionally excluded (or else they
2018-04-05 11:04:00 +00:00
// would generate duplicate lang item errors), and any globals it defines are
// _not_ the globals used by "real" std. So this import, defined only during
// testing gives test-std access to real-std lang items and globals. See #2912
2019-12-22 22:42:04 +00:00
#[cfg(test)]
extern crate std as realstd;
// The standard macros that are not built-in to the compiler.
#[macro_use]
mod macros;
// The Rust prelude
pub mod prelude;
2014-05-01 03:22:55 +00:00
// Public module declarations and re-exports
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 22:42:04 +00:00
pub use alloc_crate::borrow;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::boxed;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::fmt;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::format;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::rc;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::slice;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::str;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::string;
#[stable(feature = "rust1", since = "1.0.0")]
pub use alloc_crate::vec;
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 03:36:58 +00:00
pub use core::any;
2019-01-21 17:42:04 +00:00
#[stable(feature = "simd_arch", since = "1.27.0")]
// The `no_inline`-attribute is required to make the documentation of all
// targets available.
// See https://github.com/rust-lang/rust/pull/57808#issuecomment-457390549 for
// more information.
#[doc(no_inline)] // Note (#82861): required for correct documentation
2019-01-21 17:42:04 +00:00
pub use core::arch;
2019-12-22 22:42:04 +00:00
#[stable(feature = "core_array", since = "1.36.0")]
pub use core::array;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 18:19:56 +00:00
pub use core::cell;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 22:42:04 +00:00
pub use core::char;
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 03:55:38 +00:00
pub use core::clone;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::cmp;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::convert;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 03:46:51 +00:00
pub use core::default;
#[stable(feature = "futures_api", since = "1.36.0")]
pub use core::future;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
std: Stabilize the std::hash module This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
2014-12-09 20:37:23 +00:00
pub use core::hash;
2019-12-22 22:42:04 +00:00
#[stable(feature = "core_hint", since = "1.27.0")]
pub use core::hint;
#[stable(feature = "i128", since = "1.26.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::i128;
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::i16;
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::i32;
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::i64;
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::i8;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 03:04:56 +00:00
pub use core::intrinsics;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::isize;
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 04:41:03 +00:00
pub use core::iter;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::marker;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 03:13:05 +00:00
pub use core::mem;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::ops;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 22:42:04 +00:00
pub use core::option;
#[stable(feature = "pin", since = "1.33.0")]
pub use core::pin;
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 03:17:50 +00:00
pub use core::ptr;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
pub use core::raw;
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::result;
#[unstable(feature = "async_stream", issue = "79024")]
pub use core::stream;
2018-03-17 01:15:56 +00:00
#[stable(feature = "i128", since = "1.26.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::u128;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
pub use core::u16;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
pub use core::u32;
2015-11-16 16:54:28 +00:00
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
pub use core::u64;
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::u8;
#[stable(feature = "rust1", since = "1.0.0")]
#[allow(deprecated, deprecated_in_future)]
2019-12-22 22:42:04 +00:00
pub use core::usize;
pub mod f32;
pub mod f64;
#[macro_use]
pub mod thread;
pub mod ascii;
pub mod backtrace;
pub mod collections;
pub mod env;
pub mod error;
pub mod ffi;
pub mod fs;
pub mod io;
pub mod net;
pub mod num;
pub mod os;
pub mod panic;
pub mod path;
pub mod process;
pub mod sync;
pub mod time;
2020-07-18 00:09:47 +00:00
#[unstable(feature = "once_cell", issue = "74465")]
2020-01-12 17:14:29 +00:00
pub mod lazy;
2019-04-05 21:14:19 +00:00
#[stable(feature = "futures_api", since = "1.36.0")]
pub mod task {
//! Types and Traits for working with asynchronous tasks.
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 13:26:24 +00:00
#[doc(inline)]
2019-04-05 21:14:19 +00:00
#[stable(feature = "futures_api", since = "1.36.0")]
pub use core::task::*;
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 13:26:24 +00:00
#[doc(inline)]
#[stable(feature = "wake_trait", since = "1.51.0")]
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 13:26:24 +00:00
pub use alloc::task::*;
}
// Platform-abstraction modules
#[macro_use]
mod sys_common;
mod sys;
pub mod alloc;
// Private support modules
mod memchr;
2019-12-22 22:42:04 +00:00
mod panicking;
// The runtime entry point and a few unstable public functions used by the
// compiler
pub mod rt;
std: Switch from libbacktrace to gimli This commit is a proof-of-concept for switching the standard library's backtrace symbolication mechanism on most platforms from libbacktrace to gimli. The standard library's support for `RUST_BACKTRACE=1` requires in-process parsing of object files and DWARF debug information to interpret it and print the filename/line number of stack frames as part of a backtrace. Historically this support in the standard library has come from a library called "libbacktrace". The libbacktrace library seems to have been extracted from gcc at some point and is written in C. We've had a lot of issues with libbacktrace over time, unfortunately, though. The library does not appear to be actively maintained since we've had patches sit for months-to-years without comments. We have discovered a good number of soundness issues with the library itself, both when parsing valid DWARF as well as invalid DWARF. This is enough of an issue that the libs team has previously decided that we cannot feed untrusted inputs to libbacktrace. This also doesn't take into account the portability of libbacktrace which has been difficult to manage and maintain over time. While possible there are lots of exceptions and it's the main C dependency of the standard library right now. For years it's been the desire to switch over to a Rust-based solution for symbolicating backtraces. It's been assumed that we'll be using the Gimli family of crates for this purpose, which are targeted at safely and efficiently parsing DWARF debug information. I've been working recently to shore up the Gimli support in the `backtrace` crate. As of a few weeks ago the `backtrace` crate, by default, uses Gimli when loaded from crates.io. This transition has gone well enough that I figured it was time to start talking seriously about this change to the standard library. This commit is a preview of what's probably the best way to integrate the `backtrace` crate into the standard library with the Gimli feature turned on. While today it's used as a crates.io dependency, this commit switches the `backtrace` crate to a submodule of this repository which will need to be updated manually. This is not done lightly, but is thought to be the best solution. The primary reason for this is that the `backtrace` crate needs to do some pretty nontrivial filesystem interactions to locate debug information. Working without `std::fs` is not an option, and while it might be possible to do some sort of trait-based solution when prototyped it was found to be too unergonomic. Using a submodule allows the `backtrace` crate to build as a submodule of the `std` crate itself, enabling it to use `std::fs` and such. Otherwise this adds new dependencies to the standard library. This step requires extra attention because this means that these crates are now going to be included with all Rust programs by default. It's important to note, however, that we're already shipping libbacktrace with all Rust programs by default and it has a bunch of C code implementing all of this internally anyway, so we're basically already switching already-shipping functionality to Rust from C. * `object` - this crate is used to parse object file headers and contents. Very low-level support is used from this crate and almost all of it is disabled. Largely we're just using struct definitions as well as convenience methods internally to read bytes and such. * `addr2line` - this is the main meat of the implementation for symbolication. This crate depends on `gimli` for DWARF parsing and then provides interfaces needed by the `backtrace` crate to turn an address into a filename / line number. This crate is actually pretty small (fits in a single file almost!) and mirrors most of what `dwarf.c` does for libbacktrace. * `miniz_oxide` - the libbacktrace crate transparently handles compressed debug information which is compressed with zlib. This crate is used to decompress compressed debug sections. * `gimli` - not actually used directly, but a dependency of `addr2line`. * `adler32`- not used directly either, but a dependency of `miniz_oxide`. The goal of this change is to improve the safety of backtrace symbolication in the standard library, especially in the face of possibly malformed DWARF debug information. Even to this day we're still seeing segfaults in libbacktrace which could possibly become security vulnerabilities. This change should almost entirely eliminate this possibility whilc also paving the way forward to adding more features like split debug information. Some references for those interested are: * Original addition of libbacktrace - #12602 * OOM with libbacktrace - #24231 * Backtrace failure due to use of uninitialized value - #28447 * Possibility to feed untrusted data to libbacktrace - #21889 * Soundness fix for libbacktrace - #33729 * Crash in libbacktrace - #39468 * Support for macOS, never merged - ianlancetaylor/libbacktrace#2 * Performance issues with libbacktrace - #29293, #37477 * Update procedure is quite complicated due to how many patches we need to carry - #50955 * Libbacktrace doesn't work on MinGW with dynamic libs - #71060 * Segfault in libbacktrace on macOS - #71397 Switching to Rust will not make us immune to all of these issues. The crashes are expected to go away, but correctness and performance may still have bugs arise. The gimli and `backtrace` crates, however, are actively maintained unlike libbacktrace, so this should enable us to at least efficiently apply fixes as situations come up.
2020-05-13 21:22:37 +00:00
#[path = "../../backtrace/src/lib.rs"]
#[allow(dead_code, unused_attributes)]
mod backtrace_rs;
#[stable(feature = "simd_x86", since = "1.27.0")]
pub use std_detect::is_x86_feature_detected;
2019-01-21 17:42:04 +00:00
#[doc(hidden)]
#[unstable(feature = "stdsimd", issue = "48556")]
pub use std_detect::*;
#[unstable(feature = "stdsimd", issue = "48556")]
pub use std_detect::{
is_aarch64_feature_detected, is_arm_feature_detected, is_mips64_feature_detected,
is_mips_feature_detected, is_powerpc64_feature_detected, is_powerpc_feature_detected,
};
// Re-export macros defined in libcore.
#[stable(feature = "rust1", since = "1.0.0")]
2019-08-11 16:55:14 +00:00
#[allow(deprecated, deprecated_in_future)]
pub use core::{
2021-03-04 17:12:33 +00:00
assert_eq, assert_matches, assert_ne, debug_assert, debug_assert_eq, debug_assert_matches,
debug_assert_ne, matches, r#try, todo, unimplemented, unreachable, write, writeln,
};
// Re-export built-in macros defined through libcore.
#[stable(feature = "builtin_macro_prelude", since = "1.38.0")]
2020-04-10 16:34:30 +00:00
#[allow(deprecated)]
pub use core::{
asm, assert, cfg, column, compile_error, concat, concat_idents, env, file, format_args,
format_args_nl, global_asm, include, include_bytes, include_str, line, llvm_asm, log_syntax,
module_path, option_env, stringify, trace_macros,
};
2020-02-24 07:59:39 +00:00
#[stable(feature = "core_primitive", since = "1.43.0")]
pub use core::primitive;
2015-07-21 00:12:59 +00:00
// Include a number of private modules that exist solely to provide
// the rustdoc documentation for primitive types. Using `include!`
// because rustdoc only looks for these modules at the crate level.
include!("primitive_docs.rs");
2018-06-15 21:23:11 +00:00
// Include a number of private modules that exist solely to provide
// the rustdoc documentation for the existing keywords. Using `include!`
// because rustdoc only looks for these modules at the crate level.
include!("keyword_docs.rs");
2020-06-01 01:09:25 +00:00
// This is required to avoid an unstable error when `restricted-std` is not
// enabled. The use of #![feature(restricted_std)] in rustc-std-workspace-std
// is unconditional, so the unstable feature needs to be defined somewhere.
#[unstable(feature = "restricted_std", issue = "none")]
2020-06-01 01:09:25 +00:00
mod __restricted_std_workaround {}
mod sealed {
/// This trait being unreachable from outside the crate
/// prevents outside implementations of our extension traits.
/// This allows adding more trait methods in the future.
#[unstable(feature = "sealed", issue = "none")]
pub trait Sealed {}
}