rust/src/libstd/lib.rs

566 lines
21 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 23:16:58 +01: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 19:55:20 +01: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](prelude/index.html)
//!
//! 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 21:06:35 +02: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 21:06:35 +02: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.html) 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`](i32/index.html) that documents the constant values [`MIN`] and
//! [`MAX`](i32/constant.MAX.html) (rarely useful).
//!
//! Note the documentation for the primitives [`str`] and [`[T]`][slice] (also
//! called 'slice'). Many method calls on [`String`] and [`Vec<T>`] are actually
//! calls to methods on [`str`] and [`[T]`][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 02:56:31 +02: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 22:42:56 +02:00
//! Check out the rust contribution guidelines [here](
2020-07-04 18:41:21 +02:00
//! https://rustc-dev-guide.rust-lang.org/getting-started.html).
//! 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 22:42:56 +02: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 02:56:31 +02:00
//! regions of memory:
//!
//! * [`Vec<T>`] - A heap-allocated *vector* that is resizable at runtime.
//! * [`[T; n]`][array] - An inline *array* with a fixed size at compile time.
//! * [`[T]`][slice] - A dynamically sized *slice* into any other kind of contiguous
//! storage, whether heap-allocated or not.
2015-07-14 02:56:31 +02:00
//!
//! Slices can only be handled through some kind of *pointer*, and as such come
//! in many flavors such as:
2015-07-14 02:56:31 +02:00
//!
//! * `&[T]` - *shared slice*
//! * `&mut [T]` - *mutable slice*
//! * [`Box<[T]>`][owned slice] - *owned slice*
2015-07-14 19:25:54 +02: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/index.html
//! [`MIN`]: i32/constant.MIN.html
//! [TCP]: net/struct.TcpStream.html
//! [The Rust Prelude]: prelude/index.html
//! [UDP]: net/struct.UdpSocket.html
//! [`Arc`]: sync/struct.Arc.html
//! [owned slice]: boxed/index.html
//! [`Cell`]: cell/struct.Cell.html
//! [`FromStr`]: str/trait.FromStr.html
//! [`HashMap<K, V>`]: collections/struct.HashMap.html
//! [`Iterator`]: iter/trait.Iterator.html
//! [`Mutex`]: sync/struct.Mutex.html
//! [`Option<T>`]: option/enum.Option.html
2020-02-03 16:12:35 +01:00
//! [`Rc`]: rc/struct.Rc.html
//! [`RefCell`]: cell/struct.RefCell.html
//! [`Result<T, E>`]: result/enum.Result.html
//! [`String`]: string/struct.String.html
2020-02-03 16:12:35 +01:00
//! [`Vec<T>`]: vec/struct.Vec.html
//! [array]: primitive.array.html
//! [slice]: primitive.slice.html
//! [`atomic`]: sync/atomic/index.html
//! [`collections`]: collections/index.html
2018-11-21 01:49:47 +01:00
//! [`for`]: ../book/ch03-05-control-flow.html#looping-through-a-collection-with-for
2016-08-16 00:36:39 +02:00
//! [`format!`]: macro.format.html
//! [`fs`]: fs/index.html
//! [`io`]: io/index.html
//! [`iter`]: iter/index.html
//! [`mpsc`]: sync/mpsc/index.html
//! [`net`]: net/index.html
//! [`option`]: option/index.html
//! [`result`]: result/index.html
//! [`std::cmp`]: cmp/index.html
//! [`std::slice`]: slice/index.html
//! [`str`]: primitive.str.html
//! [`sync`]: sync/index.html
//! [`thread`]: thread/index.html
//! [`use std::env`]: env/index.html
2019-02-24 18:44:59 +01:00
//! [`use`]: ../book/ch07-02-defining-modules-to-control-scope-and-privacy.html
//! [crates.io]: https://crates.io
2018-11-21 00:42:49 +01:00
//! [deref-coercions]: ../book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods
//! [files]: fs/struct.File.html
//! [multithreading]: thread/index.html
//! [other]: #what-is-in-the-standard-library-documentation
2018-11-21 00:42:49 +01:00
//! [primitive types]: ../book/ch03-02-data-types.html
//! [rust-discord]: https://discord.gg/rust-lang
2020-06-01 03:09:25 +02: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 23:42:04 +01: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 10:16:23 +02:00
#![warn(missing_docs)]
#![warn(missing_debug_implementations)]
#![deny(intra_doc_link_resolution_failure)] // rustdoc is run without -D warnings
2019-02-10 20:23:21 +01: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)]
#![cfg_attr(test, feature(print_internals, set_stdio, update_panic_count))]
2019-12-22 23:42:04 +01:00
#![cfg_attr(
all(target_vendor = "fortanix", target_env = "sgx"),
feature(slice_index_methods, coerce_unsized, sgx_platform, ptr_wrapping_offset_from)
)]
#![cfg_attr(all(test, target_vendor = "fortanix", target_env = "sgx"), feature(fixed_size_array))]
// 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-29 01:36:22 +02:00
#![feature(allow_internal_unstable)]
2018-06-08 22:45:27 +02:00
#![feature(arbitrary_self_types)]
#![feature(array_error_internals)]
#![feature(asm)]
#![feature(associated_type_bounds)]
#![feature(atomic_mut_ptr)]
#![feature(box_syntax)]
#![feature(c_variadic)]
#![feature(can_vector)]
2020-07-10 17:59:25 +02:00
#![feature(cfg_accessible)]
#![feature(cfg_target_has_atomic)]
#![feature(cfg_target_thread_local)]
2017-05-28 00:12:16 +02:00
#![feature(char_error_internals)]
2020-05-30 11:53:50 +02:00
#![feature(char_internals)]
2019-03-09 20:10:48 +01:00
#![feature(clamp)]
#![feature(concat_idents)]
#![feature(const_cstr_unchecked)]
#![feature(const_raw_ptr_deref)]
#![feature(container_error_extra)]
#![feature(core_intrinsics)]
#![feature(custom_test_frameworks)]
2019-09-21 19:18:41 +02:00
#![feature(decl_macro)]
#![feature(doc_alias)]
#![feature(doc_cfg)]
#![feature(doc_keyword)]
#![feature(doc_masked)]
#![cfg_attr(not(bootstrap), feature(doc_spotlight))]
#![feature(dropck_eyepatch)]
2019-01-06 14:02:42 +01:00
#![feature(duration_constants)]
#![feature(exact_size_is_empty)]
#![feature(exhaustive_patterns)]
#![feature(extend_one)]
2017-12-23 03:43:09 +01:00
#![feature(external_doc)]
#![feature(fn_traits)]
#![feature(format_args_nl)]
#![feature(future_readiness_fns)]
#![feature(gen_future)]
2018-06-07 00:50:59 +02:00
#![feature(generator_trait)]
#![feature(global_asm)]
#![feature(hash_raw_entry)]
#![feature(hashmap_internals)]
#![feature(int_error_internals)]
2019-04-23 00:15:43 +02:00
#![feature(int_error_matching)]
#![feature(integer_atomics)]
2020-07-10 17:59:25 +02:00
#![feature(into_future)]
#![feature(lang_items)]
#![feature(libc)]
#![feature(link_args)]
#![feature(linkage)]
#![feature(llvm_asm)]
#![feature(log_syntax)]
#![feature(maybe_uninit_extra)]
#![feature(maybe_uninit_ref)]
#![feature(maybe_uninit_slice)]
2020-07-10 17:59:25 +02:00
#![feature(min_specialization)]
#![feature(needs_panic_runtime)]
2020-04-22 21:45:35 +02:00
#![feature(negative_impls)]
#![feature(never_type)]
2019-02-10 20:25:30 +01:00
#![feature(nll)]
#![feature(once_cell)]
#![feature(optin_builtin_traits)]
#![feature(or_patterns)]
#![feature(panic_info_message)]
#![feature(panic_internals)]
#![feature(panic_unwind)]
2016-08-22 21:47:38 +02:00
#![feature(prelude_import)]
#![feature(ptr_internals)]
#![feature(raw)]
2020-06-12 18:17:30 +02:00
#![feature(raw_ref_macros)]
2020-04-05 17:50:45 +02:00
#![feature(ready_macro)]
#![feature(renamed_spin_loop)]
#![feature(rustc_attrs)]
#![feature(rustc_private)]
#![feature(shrink_to)]
#![feature(slice_concat_ext)]
2017-12-13 08:02:19 +01:00
#![feature(slice_internals)]
#![feature(slice_strip)]
#![feature(staged_api)]
#![feature(std_internals)]
#![feature(stdsimd)]
2016-01-05 21:30:14 +01:00
#![feature(stmt_expr_attributes)]
#![feature(str_internals)]
#![feature(test)]
#![feature(thread_local)]
#![feature(toowned_clone_into)]
#![feature(total_cmp)]
#![feature(trace_macros)]
#![feature(try_reserve)]
#![feature(unboxed_closures)]
2020-07-01 05:09:06 +02:00
#![feature(unsafe_block_in_unsafe_fn)]
#![feature(untagged_unions)]
#![feature(unwind_attributes)]
#![feature(vec_into_raw_parts)]
#![feature(wake_trait)]
// 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 21:47:38 +02:00
#[prelude_import]
#[allow(unused)]
use prelude::v1::*;
// Access to Bencher, etc.
2019-12-22 23:42:04 +01: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 20:23:21 +01:00
#[allow(unused_extern_crates)]
2014-06-04 05:09:39 +02: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-09 01:18:40 +02: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-09 01:18:40 +02: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 13:04:00 +02: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 23:42:04 +01: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 05:22:55 +02:00
// Public module declarations and re-exports
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 23:42:04 +01: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 05:36:58 +02:00
pub use core::any;
2019-01-21 18:42:04 +01:00
#[stable(feature = "simd_arch", since = "1.27.0")]
#[doc(no_inline)]
pub use core::arch;
2019-12-22 23:42:04 +01:00
#[stable(feature = "core_array", since = "1.36.0")]
pub use core::array;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 20:19:56 +02:00
pub use core::cell;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 23:42:04 +01:00
pub use core::char;
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 05:55:38 +02:00
pub use core::clone;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::cmp;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::convert;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 05:46:51 +02:00
pub use core::default;
2015-11-16 17:54:28 +01: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 21:37:23 +01:00
pub use core::hash;
2019-12-22 23:42:04 +01:00
#[stable(feature = "core_hint", since = "1.27.0")]
pub use core::hint;
#[stable(feature = "i128", since = "1.26.0")]
pub use core::i128;
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::i16;
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::i32;
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::i64;
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::i8;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 05:04:56 +02:00
pub use core::intrinsics;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 23:42:04 +01:00
pub use core::isize;
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 06:41:03 +02:00
pub use core::iter;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::marker;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2014-05-01 05:13:05 +02:00
pub use core::mem;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::ops;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 23:42:04 +01: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 05:17:50 +02:00
pub use core::ptr;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::raw;
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::result;
2018-03-17 02:15:56 +01:00
#[stable(feature = "i128", since = "1.26.0")]
2019-12-22 23:42:04 +01:00
pub use core::u128;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::u16;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::u32;
2015-11-16 17:54:28 +01:00
#[stable(feature = "rust1", since = "1.0.0")]
pub use core::u64;
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 23:42:04 +01:00
pub use core::u8;
#[stable(feature = "rust1", since = "1.0.0")]
2019-12-22 23:42:04 +01: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 02:09:47 +02:00
#[unstable(feature = "once_cell", issue = "74465")]
2020-01-12 18:14:29 +01:00
pub mod lazy;
2019-04-05 23:14:19 +02: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 14:26:24 +01:00
#[doc(inline)]
2019-04-05 23:14:19 +02: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 14:26:24 +01:00
#[doc(inline)]
#[unstable(feature = "wake_trait", issue = "69912")]
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 14:26:24 +01:00
pub use alloc::task::*;
}
2019-04-05 23:14:19 +02:00
#[stable(feature = "futures_api", since = "1.36.0")]
pub mod future;
// Platform-abstraction modules
#[macro_use]
mod sys_common;
mod sys;
pub mod alloc;
// Private support modules
mod memchr;
2019-12-22 23:42:04 +01:00
mod panicking;
// The runtime entry point and a few unstable public functions used by the
// compiler
pub mod rt;
2019-01-21 18:42:04 +01:00
// Pull in the `std_detect` crate directly into libstd. The contents of
2019-07-15 13:53:44 +02:00
// `std_detect` are in a different repository: rust-lang/stdarch.
//
2019-01-21 18:42:04 +01:00
// `std_detect` depends on libstd, but the contents of this module are
// set up in such a way that directly pulling it here works such that the
// crate uses the this crate as its libstd.
2019-07-15 13:53:44 +02:00
#[path = "../stdarch/crates/std_detect/src/mod.rs"]
#[allow(missing_debug_implementations, missing_docs, dead_code)]
#[unstable(feature = "stdsimd", issue = "48556")]
#[cfg(not(test))]
2019-01-21 18:42:04 +01:00
mod std_detect;
2019-01-21 18:42:04 +01:00
#[doc(hidden)]
#[unstable(feature = "stdsimd", issue = "48556")]
#[cfg(not(test))]
2019-01-21 18:42:04 +01:00
pub use std_detect::detect;
// Re-export macros defined in libcore.
#[stable(feature = "rust1", since = "1.0.0")]
2019-08-11 18:55:14 +02:00
#[allow(deprecated, deprecated_in_future)]
pub use core::{
assert_eq, assert_ne, debug_assert, debug_assert_eq, 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 18:34:30 +02: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 08:59:39 +01:00
#[stable(feature = "core_primitive", since = "1.43.0")]
pub use core::primitive;
2015-07-21 02:12:59 +02: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 23:23:11 +02: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 03:09:25 +02: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.
#[cfg_attr(not(feature = "restricted-std"), unstable(feature = "restricted_std", issue = "none"))]
mod __restricted_std_workaround {}