2014-04-25 07:39:58 +00:00
|
|
|
//! # The Rust Standard Library
|
2013-10-31 22:09:24 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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
|
2015-10-30 21:18:26 +00:00
|
|
|
//! standard library can be accessed in [`use`] statements through the path
|
2018-12-28 21:15:55 +00:00
|
|
|
//! `std`, as in [`use std::env`].
|
2013-10-31 22:09:24 +00:00
|
|
|
//!
|
2015-07-11 19:12:19 +00:00
|
|
|
//! # 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
|
2015-10-30 21:18:26 +00:00
|
|
|
//! find it is to use the <a href="#" onclick="focusSearchBar();">search
|
|
|
|
//! bar</a> at the top of the page.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
|
|
|
//! Otherwise, you may want to jump to one of these useful sections:
|
|
|
|
//!
|
|
|
|
//! * [`std::*` modules](#modules)
|
|
|
|
//! * [Primitive types](#primitives)
|
|
|
|
//! * [Standard macros](#macros)
|
2020-08-12 21:23:07 +00:00
|
|
|
//! * [The Rust Prelude]
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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!
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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
|
2015-10-30 21:18:26 +00:00
|
|
|
//! page to collapse it into a more skimmable view.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
2018-04-01 19:06:35 +00:00
|
|
|
//! While you are looking at that `[-]` button also notice the `[src]`
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
|
|
|
//! # What is in the standard library documentation?
|
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! Second, implicit methods on [primitive types] are documented here. This can
|
2015-07-11 19:12:19 +00:00
|
|
|
//! be a source of confusion for two reasons:
|
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
|
|
|
//! So for example there is a [page for the primitive type
|
2015-10-30 21:18:26 +00:00
|
|
|
//! `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
|
2020-08-12 21:23:07 +00:00
|
|
|
//! `std::i32`] that documents the constant values [`MIN`] and [`MAX`] (rarely
|
|
|
|
//! useful).
|
2015-10-30 21:18:26 +00:00
|
|
|
//!
|
2015-10-30 21:43:05 +00:00
|
|
|
//! Note the documentation for the primitives [`str`] and [`[T]`][slice] (also
|
|
|
|
//! called 'slice'). Many method calls on [`String`] and [`Vec<T>`] are actually
|
2017-08-04 11:03:58 +00:00
|
|
|
//! calls to methods on [`str`] and [`[T]`][slice] respectively, via [deref
|
|
|
|
//! coercions][deref-coercions].
|
2015-10-30 21:18:26 +00:00
|
|
|
//!
|
|
|
|
//! 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.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
2015-07-11 19:12:19 +00:00
|
|
|
//!
|
2017-03-23 17:29:04 +00:00
|
|
|
//! # Contributing changes to the documentation
|
|
|
|
//!
|
2017-04-07 20:42:56 +00:00
|
|
|
//! Check out the rust contribution guidelines [here](
|
2020-09-25 15:26:45 +00:00
|
|
|
//! 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).
|
2017-03-23 17:48:32 +00:00
|
|
|
//! 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
|
|
|
//!
|
2017-03-23 17:48:32 +00:00
|
|
|
//! Contributions are appreciated! If you see a part of the docs that can be
|
2020-03-28 11:23:42 +00:00
|
|
|
//! improved, submit a PR, or chat with us first on [Discord][rust-discord]
|
|
|
|
//! #docs.
|
2017-03-23 17:29:04 +00:00
|
|
|
//!
|
2015-07-11 19:12:19 +00:00
|
|
|
//! # A Tour of The Rust Standard Library
|
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! The rest of this crate documentation is dedicated to pointing out notable
|
|
|
|
//! features of The Rust Standard Library.
|
2013-10-31 22:09:24 +00:00
|
|
|
//!
|
2015-05-08 22:15:03 +00:00
|
|
|
//! ## Containers and collections
|
2013-10-31 22:09:24 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
2014-04-25 07:39:58 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! The standard library exposes three common ways to deal with contiguous
|
2015-07-14 00:56:31 +00:00
|
|
|
//! regions of memory:
|
2014-04-25 07:39:58 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! * [`Vec<T>`] - A heap-allocated *vector* that is resizable at runtime.
|
2015-10-30 21:43:05 +00:00
|
|
|
//! * [`[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
|
2015-10-30 21:18:26 +00:00
|
|
|
//! storage, whether heap-allocated or not.
|
2015-07-14 00:56:31 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +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*
|
2015-10-30 21:43:05 +00:00
|
|
|
//! * [`Box<[T]>`][owned slice] - *owned slice*
|
2015-07-14 17:25:54 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +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.
|
2014-04-25 07:39:58 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! For converting to strings use the [`format!`] macro, and for converting from
|
|
|
|
//! strings use the [`FromStr`] trait.
|
2014-04-25 07:39:58 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
2015-05-08 22:15:03 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! The [`collections`] module defines maps, sets, linked lists and other
|
|
|
|
//! typical collection types, including the common [`HashMap<K, V>`].
|
2015-05-08 22:15:03 +00:00
|
|
|
//!
|
|
|
|
//! ## Platform abstractions and I/O
|
2014-04-25 07:39:58 +00:00
|
|
|
//!
|
2015-10-30 21:18:26 +00:00
|
|
|
//! 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.
|
|
|
|
//!
|
2020-08-12 21:23:07 +00:00
|
|
|
//! [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
|
2020-08-12 21:23:07 +00:00
|
|
|
//! [`mpsc`]: sync::mpsc
|
|
|
|
//! [`std::cmp`]: cmp
|
|
|
|
//! [`std::slice`]: slice
|
2015-10-30 21:18:26 +00:00
|
|
|
//! [`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
|
2015-10-30 21:18:26 +00:00
|
|
|
//! [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
|
2020-08-12 21:23:07 +00:00
|
|
|
//! [files]: fs::File
|
|
|
|
//! [multithreading]: thread
|
2015-10-30 21:18:26 +00:00
|
|
|
//! [other]: #what-is-in-the-standard-library-documentation
|
2018-11-20 23:42:49 +00:00
|
|
|
//! [primitive types]: ../book/ch03-02-data-types.html
|
2020-03-28 11:23:42 +00:00
|
|
|
//! [rust-discord]: https://discord.gg/rust-lang
|
2015-05-08 22:15:03 +00:00
|
|
|
|
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)))
|
|
|
|
)]
|
2016-10-01 01:38:29 +00:00
|
|
|
// Don't link to std. We are std.
|
|
|
|
#![no_std]
|
2019-07-17 07:33:08 +00:00
|
|
|
#![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)]
|
2019-07-23 19:17:27 +00:00
|
|
|
#![allow(unused_lifetimes)]
|
2016-10-01 01:38:29 +00:00
|
|
|
// Tell the compiler to link to either panic_abort or panic_unwind
|
2016-05-24 05:28:15 +00:00
|
|
|
#![needs_panic_runtime]
|
2016-10-01 01:38:29 +00:00
|
|
|
// std may use features in a platform-specific way
|
|
|
|
#![allow(unused_features)]
|
2020-10-21 18:54:20 +00:00
|
|
|
#![cfg_attr(not(bootstrap), feature(rustc_allow_const_fn_unstable))]
|
2019-07-27 12:06:49 +00:00
|
|
|
#![cfg_attr(test, feature(print_internals, set_stdio, update_panic_count))]
|
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
|
|
|
)]
|
2020-07-20 10:23:47 +00:00
|
|
|
#![cfg_attr(all(test, target_vendor = "fortanix", target_env = "sgx"), feature(fixed_size_array))]
|
2016-10-01 01:38:29 +00:00
|
|
|
// std is implemented with unstable features, many of which are internal
|
|
|
|
// compiler details that will never be stable
|
2019-02-22 08:04:10 +00:00
|
|
|
// NB: the following list is sorted to minimize merge conflicts.
|
2018-07-06 13:49:52 +00:00
|
|
|
#![feature(alloc_error_handler)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(alloc_layout_extra)]
|
2018-07-06 13:49:52 +00:00
|
|
|
#![feature(allocator_api)]
|
2017-06-03 21:54:08 +00:00
|
|
|
#![feature(allocator_internals)]
|
2017-08-08 15:22:51 +00:00
|
|
|
#![feature(allow_internal_unsafe)]
|
2015-04-28 23:36:22 +00:00
|
|
|
#![feature(allow_internal_unstable)]
|
2018-06-08 20:45:27 +00:00
|
|
|
#![feature(arbitrary_self_types)]
|
2017-09-29 17:30:03 +00:00
|
|
|
#![feature(array_error_internals)]
|
2015-11-03 00:23:22 +00:00
|
|
|
#![feature(asm)]
|
2019-08-08 22:33:57 +00:00
|
|
|
#![feature(associated_type_bounds)]
|
2019-12-26 17:55:13 +00:00
|
|
|
#![feature(atomic_mut_ptr)]
|
2020-09-27 13:19:42 +00:00
|
|
|
#![feature(bool_to_option)]
|
2015-01-07 14:15:34 +00:00
|
|
|
#![feature(box_syntax)]
|
2018-10-23 23:13:33 +00:00
|
|
|
#![feature(c_variadic)]
|
2020-07-10 15:59:25 +00:00
|
|
|
#![feature(cfg_accessible)]
|
2016-10-14 19:31:15 +00:00
|
|
|
#![feature(cfg_target_has_atomic)]
|
2015-12-11 20:42:29 +00:00
|
|
|
#![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)]
|
2019-03-09 19:10:48 +00:00
|
|
|
#![feature(clamp)]
|
2018-12-19 14:13:43 +00:00
|
|
|
#![feature(concat_idents)]
|
2018-10-02 11:26:16 +00:00
|
|
|
#![feature(const_cstr_unchecked)]
|
2020-10-07 22:56:26 +00:00
|
|
|
#![feature(const_fn_floating_point_arithmetic)]
|
2020-08-05 10:29:38 +00:00
|
|
|
#![feature(const_fn_transmute)]
|
2020-09-17 18:02:56 +00:00
|
|
|
#![feature(const_fn)]
|
2020-10-07 22:56:26 +00:00
|
|
|
#![feature(const_fn_fn_ptr_basics)]
|
2020-09-07 15:43:48 +00:00
|
|
|
#![feature(const_ip)]
|
2020-09-01 17:00:20 +00:00
|
|
|
#![feature(const_ipv6)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(const_raw_ptr_deref)]
|
2020-09-01 17:50:01 +00:00
|
|
|
#![feature(const_ipv4)]
|
2019-06-12 16:47:58 +00:00
|
|
|
#![feature(container_error_extra)]
|
2015-06-09 18:18:03 +00:00
|
|
|
#![feature(core_intrinsics)]
|
2019-06-20 08:52:31 +00:00
|
|
|
#![feature(custom_test_frameworks)]
|
2019-09-21 17:18:41 +00:00
|
|
|
#![feature(decl_macro)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(doc_cfg)]
|
|
|
|
#![feature(doc_keyword)]
|
|
|
|
#![feature(doc_masked)]
|
2020-08-27 08:58:34 +00:00
|
|
|
#![feature(doc_spotlight)]
|
2016-12-28 22:47:10 +00:00
|
|
|
#![feature(dropck_eyepatch)]
|
2019-01-06 13:02:42 +00:00
|
|
|
#![feature(duration_constants)]
|
2016-12-03 20:59:00 +00:00
|
|
|
#![feature(exact_size_is_empty)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(exhaustive_patterns)]
|
2020-05-13 03:09:55 +00:00
|
|
|
#![feature(extend_one)]
|
2017-12-23 02:43:09 +00:00
|
|
|
#![feature(external_doc)]
|
2020-10-19 20:31:11 +00:00
|
|
|
#![feature(fmt_as_str)]
|
2016-03-07 17:20:25 +00:00
|
|
|
#![feature(fn_traits)]
|
2019-06-20 08:52:31 +00:00
|
|
|
#![feature(format_args_nl)]
|
2020-05-22 08:07:46 +00:00
|
|
|
#![feature(gen_future)]
|
2018-06-06 22:50:59 +00:00
|
|
|
#![feature(generator_trait)]
|
2019-06-20 08:52:31 +00:00
|
|
|
#![feature(global_asm)]
|
2018-03-17 10:07:50 +00:00
|
|
|
#![feature(hashmap_internals)]
|
2015-06-09 18:18:03 +00:00
|
|
|
#![feature(int_error_internals)]
|
2019-04-22 22:15:43 +00:00
|
|
|
#![feature(int_error_matching)]
|
2016-10-14 19:31:15 +00:00
|
|
|
#![feature(integer_atomics)]
|
2020-07-10 15:59:25 +00:00
|
|
|
#![feature(into_future)]
|
2015-02-11 12:57:40 +00:00
|
|
|
#![feature(lang_items)]
|
2015-11-03 00:23:22 +00:00
|
|
|
#![feature(link_args)]
|
|
|
|
#![feature(linkage)]
|
2020-01-14 13:40:42 +00:00
|
|
|
#![feature(llvm_asm)]
|
2019-06-20 08:52:31 +00:00
|
|
|
#![feature(log_syntax)]
|
2020-01-14 03:34:23 +00:00
|
|
|
#![feature(maybe_uninit_extra)]
|
2019-07-17 07:51:58 +00:00
|
|
|
#![feature(maybe_uninit_ref)]
|
2019-07-22 21:17:37 +00:00
|
|
|
#![feature(maybe_uninit_slice)]
|
2020-07-10 15:59:25 +00:00
|
|
|
#![feature(min_specialization)]
|
2016-07-27 10:10:31 +00:00
|
|
|
#![feature(needs_panic_runtime)]
|
2020-04-22 19:45:35 +00:00
|
|
|
#![feature(negative_impls)]
|
2019-12-11 14:55:29 +00:00
|
|
|
#![feature(never_type)]
|
2019-02-10 19:25:30 +00:00
|
|
|
#![feature(nll)]
|
2020-08-04 16:03:34 +00:00
|
|
|
#![feature(nonnull_slice_from_raw_parts)]
|
2020-01-14 03:34:23 +00:00
|
|
|
#![feature(once_cell)]
|
2015-01-30 20:26:44 +00:00
|
|
|
#![feature(optin_builtin_traits)]
|
2020-04-16 19:44:57 +00:00
|
|
|
#![feature(or_patterns)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(panic_info_message)]
|
2018-01-23 15:31:53 +00:00
|
|
|
#![feature(panic_internals)]
|
2017-08-22 01:30:51 +00:00
|
|
|
#![feature(panic_unwind)]
|
2016-08-22 19:47:38 +00:00
|
|
|
#![feature(prelude_import)]
|
2017-12-22 18:29:16 +00:00
|
|
|
#![feature(ptr_internals)]
|
2015-06-09 18:18:03 +00:00
|
|
|
#![feature(raw)]
|
2020-06-12 16:17:30 +00:00
|
|
|
#![feature(raw_ref_macros)]
|
2020-04-05 15:50:45 +00:00
|
|
|
#![feature(ready_macro)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(renamed_spin_loop)]
|
2016-03-10 19:20:09 +00:00
|
|
|
#![feature(rustc_attrs)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(rustc_private)]
|
2018-03-26 22:24:31 +00:00
|
|
|
#![feature(shrink_to)]
|
2015-11-03 00:23:22 +00:00
|
|
|
#![feature(slice_concat_ext)]
|
2017-12-13 07:02:19 +00:00
|
|
|
#![feature(slice_internals)]
|
2020-08-04 16:03:34 +00:00
|
|
|
#![feature(slice_ptr_get)]
|
|
|
|
#![feature(slice_ptr_len)]
|
2020-07-10 15:59:25 +00:00
|
|
|
#![feature(slice_strip)]
|
2015-01-30 20:26:44 +00:00
|
|
|
#![feature(staged_api)]
|
2019-02-22 08:04:10 +00:00
|
|
|
#![feature(std_internals)]
|
|
|
|
#![feature(stdsimd)]
|
2016-01-05 20:30:14 +00:00
|
|
|
#![feature(stmt_expr_attributes)]
|
2015-06-09 18:18:03 +00:00
|
|
|
#![feature(str_internals)]
|
2019-07-27 12:06:49 +00:00
|
|
|
#![feature(test)]
|
2015-11-03 00:23:22 +00:00
|
|
|
#![feature(thread_local)]
|
2020-09-17 18:02:56 +00:00
|
|
|
#![feature(thread_local_internals)]
|
2017-04-13 09:48:46 +00:00
|
|
|
#![feature(toowned_clone_into)]
|
2020-05-22 19:41:24 +00:00
|
|
|
#![feature(total_cmp)]
|
2019-06-20 08:52:31 +00:00
|
|
|
#![feature(trace_macros)]
|
2018-03-08 14:36:43 +00:00
|
|
|
#![feature(try_reserve)]
|
2015-01-30 20:26:44 +00:00
|
|
|
#![feature(unboxed_closures)]
|
2020-07-01 03:09:06 +00:00
|
|
|
#![feature(unsafe_block_in_unsafe_fn)]
|
2020-09-19 19:33:40 +00:00
|
|
|
#![feature(unsafe_cell_get_mut)]
|
2020-09-16 19:16:32 +00:00
|
|
|
#![feature(unsafe_cell_raw_get)]
|
2020-10-05 07:20:39 +00:00
|
|
|
#![cfg_attr(bootstrap, feature(untagged_unions))]
|
2015-09-11 18:10:43 +00:00
|
|
|
#![feature(unwind_attributes)]
|
2019-09-01 15:23:20 +00:00
|
|
|
#![feature(vec_into_raw_parts)]
|
2020-01-31 13:43:41 +00:00
|
|
|
#![feature(wake_trait)]
|
2019-02-22 08:04:10 +00:00
|
|
|
// NB: the above list is sorted to minimize merge conflicts.
|
2017-07-17 16:32:08 +00:00
|
|
|
#![default_lib_allocator]
|
2017-06-03 21:54:08 +00:00
|
|
|
|
2016-10-01 01:38:29 +00:00
|
|
|
// 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::*;
|
|
|
|
|
2016-10-01 01:38:29 +00:00
|
|
|
// Access to Bencher, etc.
|
2019-12-22 22:42:04 +00:00
|
|
|
#[cfg(test)]
|
|
|
|
extern crate test;
|
2013-10-22 22:13:18 +00:00
|
|
|
|
2018-04-30 11:06:24 +00:00
|
|
|
#[allow(unused_imports)] // macros from `alloc` are not used on all platforms
|
2015-01-01 04:43:46 +00:00
|
|
|
#[macro_use]
|
2018-04-03 12:36:57 +00:00
|
|
|
extern crate alloc as alloc_crate;
|
2017-08-21 18:43:45 +00:00
|
|
|
#[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;
|
2014-02-24 18:16:03 +00:00
|
|
|
|
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
|
2017-08-21 18:43:45 +00:00
|
|
|
#[doc(masked)]
|
2017-08-22 01:30:51 +00:00
|
|
|
#[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;
|
|
|
|
|
2016-10-01 01:38:29 +00:00
|
|
|
// 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
|
2016-10-01 01:38:29 +00:00
|
|
|
// _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;
|
2014-05-20 17:38:05 +00:00
|
|
|
|
2016-10-01 01:38:29 +00:00
|
|
|
// The standard macros that are not built-in to the compiler.
|
|
|
|
#[macro_use]
|
2019-10-23 13:30:04 +00:00
|
|
|
mod macros;
|
2016-10-01 01:38:29 +00:00
|
|
|
|
|
|
|
// The Rust prelude
|
|
|
|
pub mod prelude;
|
2014-05-01 03:22:55 +00:00
|
|
|
|
2018-01-12 21:41:25 +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")]
|
|
|
|
#[doc(no_inline)]
|
|
|
|
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")]
|
2015-07-28 23:22:05 +00:00
|
|
|
pub use core::cmp;
|
2015-11-16 16:54:28 +00:00
|
|
|
#[stable(feature = "rust1", since = "1.0.0")]
|
2015-03-18 16:14:54 +00:00
|
|
|
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;
|
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")]
|
|
|
|
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 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")]
|
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")]
|
2015-07-28 23:22:05 +00:00
|
|
|
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")]
|
2015-07-28 23:22:05 +00:00
|
|
|
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")]
|
2018-06-22 18:36:01 +00:00
|
|
|
pub use core::raw;
|
|
|
|
#[stable(feature = "rust1", since = "1.0.0")]
|
2014-05-10 20:46:05 +00:00
|
|
|
pub use core::result;
|
2018-03-17 01:15:56 +00:00
|
|
|
#[stable(feature = "i128", since = "1.26.0")]
|
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")]
|
2015-08-17 20:23:36 +00:00
|
|
|
pub use core::u16;
|
2015-11-16 16:54:28 +00:00
|
|
|
#[stable(feature = "rust1", since = "1.0.0")]
|
2015-08-17 20:23:36 +00:00
|
|
|
pub use core::u32;
|
2015-11-16 16:54:28 +00:00
|
|
|
#[stable(feature = "rust1", since = "1.0.0")]
|
2015-08-17 20:23:36 +00:00
|
|
|
pub use core::u64;
|
2016-10-01 01:38:29 +00:00
|
|
|
#[stable(feature = "rust1", since = "1.0.0")]
|
2019-12-22 22:42:04 +00:00
|
|
|
pub use core::u8;
|
2016-10-01 01:38:29 +00:00
|
|
|
#[stable(feature = "rust1", since = "1.0.0")]
|
2019-12-22 22:42:04 +00:00
|
|
|
pub use core::usize;
|
2013-05-13 01:14:40 +00:00
|
|
|
|
2016-10-01 23:07:17 +00:00
|
|
|
pub mod f32;
|
|
|
|
pub mod f64;
|
2012-11-30 08:47:45 +00:00
|
|
|
|
2015-01-06 17:24:46 +00:00
|
|
|
#[macro_use]
|
2015-03-20 07:46:13 +00:00
|
|
|
pub mod thread;
|
2016-10-01 01:38:29 +00:00
|
|
|
pub mod ascii;
|
2019-09-04 20:00:14 +00:00
|
|
|
pub mod backtrace;
|
2015-03-20 07:46:13 +00:00
|
|
|
pub mod collections;
|
|
|
|
pub mod env;
|
2016-10-01 01:38:29 +00:00
|
|
|
pub mod error;
|
2014-11-25 21:28:35 +00:00
|
|
|
pub mod ffi;
|
2015-02-03 05:39:14 +00:00
|
|
|
pub mod fs;
|
2015-03-20 07:46:13 +00:00
|
|
|
pub mod io;
|
2015-02-06 00:50:11 +00:00
|
|
|
pub mod net;
|
2016-10-01 01:38:29 +00:00
|
|
|
pub mod num;
|
2014-11-14 22:20:57 +00:00
|
|
|
pub mod os;
|
2015-08-31 15:51:53 +00:00
|
|
|
pub mod panic;
|
2014-11-14 22:20:57 +00:00
|
|
|
pub mod path;
|
2015-02-06 17:42:57 +00:00
|
|
|
pub mod process;
|
2013-12-13 01:27:37 +00:00
|
|
|
pub mod sync;
|
2015-03-20 07:46:13 +00:00
|
|
|
pub mod time;
|
2018-04-03 12:41:15 +00:00
|
|
|
|
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")]
|
2018-06-22 18:36:01 +00:00
|
|
|
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
|
|
|
|
2018-06-22 18:36:01 +00:00
|
|
|
#[doc(inline)]
|
2019-04-05 21:14:19 +00:00
|
|
|
#[stable(feature = "futures_api", since = "1.36.0")]
|
2018-06-22 18:36:01 +00:00
|
|
|
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)]
|
2020-03-23 00:35:01 +00:00
|
|
|
#[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 13:26:24 +00:00
|
|
|
pub use alloc::task::*;
|
2018-06-22 18:36:01 +00:00
|
|
|
}
|
|
|
|
|
2019-04-05 21:14:19 +00:00
|
|
|
#[stable(feature = "futures_api", since = "1.36.0")]
|
2018-06-22 18:36:01 +00:00
|
|
|
pub mod future;
|
|
|
|
|
2016-10-01 01:38:29 +00:00
|
|
|
// Platform-abstraction modules
|
2015-03-10 03:04:35 +00:00
|
|
|
#[macro_use]
|
2016-09-30 23:26:44 +00:00
|
|
|
mod sys_common;
|
2016-09-30 22:11:46 +00:00
|
|
|
mod sys;
|
2014-10-01 00:03:56 +00:00
|
|
|
|
2018-04-21 04:05:13 +00:00
|
|
|
pub mod alloc;
|
|
|
|
|
2016-10-01 01:38:29 +00:00
|
|
|
// Private support modules
|
|
|
|
mod memchr;
|
2019-12-22 22:42:04 +00:00
|
|
|
mod panicking;
|
2016-10-01 01:38:29 +00:00
|
|
|
|
|
|
|
// The runtime entry point and a few unstable public functions used by the
|
|
|
|
// compiler
|
|
|
|
pub mod rt;
|
2012-11-30 08:47:45 +00:00
|
|
|
|
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;
|
|
|
|
|
2019-01-21 17:42:04 +00:00
|
|
|
// Pull in the `std_detect` crate directly into libstd. The contents of
|
2019-07-15 11:53:44 +00:00
|
|
|
// `std_detect` are in a different repository: rust-lang/stdarch.
|
2018-02-18 01:23:19 +00:00
|
|
|
//
|
2019-01-21 17:42:04 +00: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.
|
2020-06-12 02:31:49 +00:00
|
|
|
#[path = "../../stdarch/crates/std_detect/src/mod.rs"]
|
2018-02-18 01:23:19 +00:00
|
|
|
#[allow(missing_debug_implementations, missing_docs, dead_code)]
|
|
|
|
#[unstable(feature = "stdsimd", issue = "48556")]
|
2018-12-08 11:06:54 +00:00
|
|
|
#[cfg(not(test))]
|
2019-01-21 17:42:04 +00:00
|
|
|
mod std_detect;
|
2018-02-18 01:23:19 +00:00
|
|
|
|
2019-01-21 17:42:04 +00:00
|
|
|
#[doc(hidden)]
|
|
|
|
#[unstable(feature = "stdsimd", issue = "48556")]
|
2018-12-08 11:06:54 +00:00
|
|
|
#[cfg(not(test))]
|
2019-01-21 17:42:04 +00:00
|
|
|
pub use std_detect::detect;
|
2018-02-18 01:23:19 +00:00
|
|
|
|
2019-07-27 22:51:21 +00:00
|
|
|
// 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)]
|
2019-07-27 22:51:21 +00:00
|
|
|
pub use core::{
|
2020-04-05 18:59:10 +00:00
|
|
|
assert_eq, assert_ne, debug_assert, debug_assert_eq, debug_assert_ne, matches, r#try, todo,
|
|
|
|
unimplemented, unreachable, write, writeln,
|
2019-07-27 22:51:21 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// Re-export built-in macros defined through libcore.
|
2019-06-20 08:52:31 +00:00
|
|
|
#[stable(feature = "builtin_macro_prelude", since = "1.38.0")]
|
2020-04-10 16:34:30 +00:00
|
|
|
#[allow(deprecated)]
|
2019-07-27 22:51:21 +00:00
|
|
|
pub use core::{
|
2020-01-14 13:40:42 +00:00
|
|
|
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,
|
2019-06-20 08:52:31 +00:00
|
|
|
};
|
|
|
|
|
2020-02-24 07:59:39 +00:00
|
|
|
#[stable(feature = "core_primitive", since = "1.43.0")]
|
2019-12-26 17:55:13 +00:00
|
|
|
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.
|
2015-07-20 18:21:02 +00:00
|
|
|
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.
|
|
|
|
#[cfg_attr(not(feature = "restricted-std"), unstable(feature = "restricted_std", issue = "none"))]
|
|
|
|
mod __restricted_std_workaround {}
|