Rollup of 8 pull requests

src/bootstrap/builder.rs

@@ -324,7 +324,7 @@ impl<'a> Builder<'a> {
         StepDescription::run(&Builder::get_step_descriptions(Kind::Doc), self, paths);
     }
 
-    /// Obtain a compiler at a given stage and for a given host. Explictly does
+    /// Obtain a compiler at a given stage and for a given host. Explicitly does
     /// not take `Compiler` since all `Compiler` instances are meant to be
     /// obtained through this function, since it ensures that they are valid
     /// (i.e., built and assembled).
@@ -489,7 +489,7 @@ impl<'a> Builder<'a> {
             // crates). Let's say, for example that rustc itself depends on the
             // bitflags crate. If an external crate then depends on the
             // bitflags crate as well, we need to make sure they don't
-            // conflict, even if they pick the same verison of bitflags. We'll
+            // conflict, even if they pick the same version of bitflags. We'll
             // want to make sure that e.g. a plugin and rustc each get their
             // own copy of bitflags.
 

src/bootstrap/doc.rs

@@ -306,7 +306,7 @@ impl Step for Standalone {
     ///
     /// This will list all of `src/doc` looking for markdown files and appropriately
     /// perform transformations like substituting `VERSION`, `SHORT_HASH`, and
-    /// `STAMP` alongw ith providing the various header/footer HTML we've cutomized.
+    /// `STAMP` along with providing the various header/footer HTML we've customized.
     ///
     /// In the end, this is just a glorified wrapper around rustdoc!
     fn run(self, builder: &Builder) {

src/liballoc/allocator.rs

@@ -240,7 +240,7 @@ impl Layout {
     ///
     /// Returns `Some((k, offset))`, where `k` is layout of the concatenated
     /// record and `offset` is the relative location, in bytes, of the
-    /// start of the `next` embedded witnin the concatenated record
+    /// start of the `next` embedded within the concatenated record
     /// (assuming that the record itself starts at offset 0).
     ///
     /// On arithmetic overflow, returns `None`.
@@ -297,7 +297,7 @@ impl Layout {
     ///
     /// Returns `(k, offset)`, where `k` is layout of the concatenated
     /// record and `offset` is the relative location, in bytes, of the
-    /// start of the `next` embedded witnin the concatenated record
+    /// start of the `next` embedded within the concatenated record
     /// (assuming that the record itself starts at offset 0).
     ///
     /// (The `offset` is always the same as `self.size()`; we use this
@@ -544,7 +544,7 @@ pub unsafe trait Alloc {
     /// practice this means implementors should eschew allocating,
     /// especially from `self` (directly or indirectly).
     ///
-    /// Implementions of the allocation and reallocation methods
+    /// Implementations of the allocation and reallocation methods
     /// (e.g. `alloc`, `alloc_one`, `realloc`) are discouraged from
     /// panicking (or aborting) in the event of memory exhaustion;
     /// instead they should return an appropriate error from the

src/liballoc/fmt.rs

@@ -10,16 +10,16 @@
 
 //! Utilities for formatting and printing `String`s
 //!
-//! This module contains the runtime support for the `format!` syntax extension.
+//! This module contains the runtime support for the [`format!`] syntax extension.
 //! This macro is implemented in the compiler to emit calls to this module in
 //! order to format arguments at runtime into strings.
 //!
 //! # Usage
 //!
-//! The `format!` macro is intended to be familiar to those coming from C's
-//! printf/fprintf functions or Python's `str.format` function.
+//! The [`format!`] macro is intended to be familiar to those coming from C's
+//! `printf`/`fprintf` functions or Python's `str.format` function.
 //!
-//! Some examples of the `format!` extension are:
+//! Some examples of the [`format!`] extension are:
 //!
 //! ```
 //! format!("Hello");                 // => "Hello"
@@ -67,15 +67,15 @@
 //! ## Named parameters
 //!
 //! Rust itself does not have a Python-like equivalent of named parameters to a
-//! function, but the `format!` macro is a syntax extension which allows it to
+//! function, but the [`format!`] macro is a syntax extension which allows it to
 //! leverage named parameters. Named parameters are listed at the end of the
 //! argument list and have the syntax:
 //!
 //! ```text
 //! identifier '=' expression
 //! ```
 //!
-//! For example, the following `format!` expressions all use named argument:
+//! For example, the following [`format!`] expressions all use named argument:
 //!
 //! ```
 //! format!("{argument}", argument = "test");   // => "test"
@@ -102,30 +102,30 @@
 //!
 //! If this syntax is used, then the number of characters to print precedes the
 //! actual object being formatted, and the number of characters must have the
-//! type `usize`.
+//! type [`usize`].
 //!
 //! ## Formatting traits
 //!
 //! When requesting that an argument be formatted with a particular type, you
 //! are actually requesting that an argument ascribes to a particular trait.
-//! This allows multiple actual types to be formatted via `{:x}` (like `i8` as
-//! well as `isize`).  The current mapping of types to traits is:
+//! This allows multiple actual types to be formatted via `{:x}` (like [`i8`] as
+//! well as [`isize`]).  The current mapping of types to traits is:
 //!
-//! * *nothing* ⇒ [`Display`](trait.Display.html)
-//! * `?` ⇒ [`Debug`](trait.Debug.html)
+//! * *nothing* ⇒ [`Display`]
+//! * `?` ⇒ [`Debug`]
 //! * `o` ⇒ [`Octal`](trait.Octal.html)
 //! * `x` ⇒ [`LowerHex`](trait.LowerHex.html)
 //! * `X` ⇒ [`UpperHex`](trait.UpperHex.html)
 //! * `p` ⇒ [`Pointer`](trait.Pointer.html)
-//! * `b` ⇒ [`Binary`](trait.Binary.html)
+//! * `b` ⇒ [`Binary`]
 //! * `e` ⇒ [`LowerExp`](trait.LowerExp.html)
 //! * `E` ⇒ [`UpperExp`](trait.UpperExp.html)
 //!
 //! What this means is that any type of argument which implements the
-//! `fmt::Binary` trait can then be formatted with `{:b}`. Implementations
+//! [`fmt::Binary`][`Binary`] trait can then be formatted with `{:b}`. Implementations
 //! are provided for these traits for a number of primitive types by the
 //! standard library as well. If no format is specified (as in `{}` or `{:6}`),
-//! then the format trait used is the `Display` trait.
+//! then the format trait used is the [`Display`] trait.
 //!
 //! When implementing a format trait for your own type, you will have to
 //! implement a method of the signature:
@@ -144,15 +144,15 @@
 //! should emit output into the `f.buf` stream. It is up to each format trait
 //! implementation to correctly adhere to the requested formatting parameters.
 //! The values of these parameters will be listed in the fields of the
-//! `Formatter` struct. In order to help with this, the `Formatter` struct also
+//! [`Formatter`] struct. In order to help with this, the [`Formatter`] struct also
 //! provides some helper methods.
 //!
-//! Additionally, the return value of this function is `fmt::Result` which is a
-//! type alias of `Result<(), std::fmt::Error>`. Formatting implementations
-//! should ensure that they propagate errors from the `Formatter` (e.g., when
-//! calling `write!`) however, they should never return errors spuriously. That
+//! Additionally, the return value of this function is [`fmt::Result`] which is a
+//! type alias of [`Result`]`<(), `[`std::fmt::Error`]`>`. Formatting implementations
+//! should ensure that they propagate errors from the [`Formatter`][`Formatter`] (e.g., when
+//! calling [`write!`]) however, they should never return errors spuriously. That
 //! is, a formatting implementation must and may only return an error if the
-//! passed-in `Formatter` returns an error. This is because, contrary to what
+//! passed-in [`Formatter`] returns an error. This is because, contrary to what
 //! the function signature might suggest, string formatting is an infallible
 //! operation. This function only returns a result because writing to the
 //! underlying stream might fail and it must provide a way to propagate the fact
@@ -209,12 +209,12 @@
 //!
 //! These two formatting traits have distinct purposes:
 //!
-//! - `fmt::Display` implementations assert that the type can be faithfully
+//! - [`fmt::Display`][`Display`] implementations assert that the type can be faithfully
 //!   represented as a UTF-8 string at all times. It is **not** expected that
 //!   all types implement the `Display` trait.
-//! - `fmt::Debug` implementations should be implemented for **all** public types.
+//! - [`fmt::Debug`][`Debug`] implementations should be implemented for **all** public types.
 //!   Output will typically represent the internal state as faithfully as possible.
-//!   The purpose of the `Debug` trait is to facilitate debugging Rust code. In
+//!   The purpose of the [`Debug`] trait is to facilitate debugging Rust code. In
 //!   most cases, using `#[derive(Debug)]` is sufficient and recommended.
 //!
 //! Some examples of the output from both traits:
@@ -227,7 +227,7 @@
 //!
 //! ## Related macros
 //!
-//! There are a number of related macros in the `format!` family. The ones that
+//! There are a number of related macros in the [`format!`] family. The ones that
 //! are currently implemented are:
 //!
 //! ```ignore (only-for-syntax-highlight)
@@ -241,11 +241,11 @@
 //!
 //! ### `write!`
 //!
-//! This and `writeln` are two macros which are used to emit the format string
+//! This and [`writeln!`] are two macros which are used to emit the format string
 //! to a specified stream. This is used to prevent intermediate allocations of
 //! format strings and instead directly write the output. Under the hood, this
-//! function is actually invoking the `write_fmt` function defined on the
-//! `std::io::Write` trait. Example usage is:
+//! function is actually invoking the [`write_fmt`] function defined on the
+//! [`std::io::Write`] trait. Example usage is:
 //!
 //! ```
 //! # #![allow(unused_must_use)]
@@ -256,7 +256,7 @@
 //!
 //! ### `print!`
 //!
-//! This and `println` emit their output to stdout. Similarly to the `write!`
+//! This and [`println!`] emit their output to stdout. Similarly to the [`write!`]
 //! macro, the goal of these macros is to avoid intermediate allocations when
 //! printing output. Example usage is:
 //!
@@ -288,8 +288,8 @@
 //! my_fmt_fn(format_args!(", or a {} too", "function"));
 //! ```
 //!
-//! The result of the `format_args!` macro is a value of type `fmt::Arguments`.
-//! This structure can then be passed to the `write` and `format` functions
+//! The result of the [`format_args!`] macro is a value of type [`fmt::Arguments`].
+//! This structure can then be passed to the [`write`] and [`format`] functions
 //! inside this module in order to process the format string.
 //! The goal of this macro is to even further prevent intermediate allocations
 //! when dealing formatting strings.
@@ -357,7 +357,7 @@
 //! * `-` - Currently not used
 //! * `#` - This flag is indicates that the "alternate" form of printing should
 //!         be used. The alternate forms are:
-//!     * `#?` - pretty-print the `Debug` formatting
+//!     * `#?` - pretty-print the [`Debug`] formatting
 //!     * `#x` - precedes the argument with a `0x`
 //!     * `#X` - precedes the argument with a `0x`
 //!     * `#b` - precedes the argument with a `0b`
@@ -384,9 +384,9 @@
 //! the `0` flag is specified for numerics, then the implicit fill character is
 //! `0`.
 //!
-//! The value for the width can also be provided as a `usize` in the list of
+//! The value for the width can also be provided as a [`usize`] in the list of
 //! parameters by using the dollar syntax indicating that the second argument is
-//! a `usize` specifying the width, for example:
+//! a [`usize`] specifying the width, for example:
 //!
 //! ```
 //! // All of these print "Hello x    !"
@@ -474,6 +474,29 @@
 //! The literal characters `{` and `}` may be included in a string by preceding
 //! them with the same character. For example, the `{` character is escaped with
 //! `{{` and the `}` character is escaped with `}}`.
+//!
+//! [`format!`]: ../../macro.format.html
+//! [`usize`]: ../../std/primitive.usize.html
+//! [`isize`]: ../../std/primitive.isize.html
+//! [`i8`]: ../../std/primitive.i8.html
+//! [`Display`]: trait.Display.html
+//! [`Binary`]: trait.Binary.html
+//! [`fmt::Result`]: type.Result.html
+//! [`Result`]: ../../std/result/enum.Result.html
+//! [`std::fmt::Error`]: struct.Error.html
+//! [`Formatter`]: struct.Formatter.html
+//! [`write!`]: ../../std/macro.write.html
+//! [`Debug`]: trait.Debug.html
+//! [`format!`]: ../../std/macro.format.html
+//! [`writeln!`]: ../../std/macro.writeln.html
+//! [`write_fmt`]: ../../std/io/trait.Write.html#method.write_fmt
+//! [`std::io::Write`]: ../../std/io/trait.Write.html
+//! [`println!`]: ../../std/macro.println.html
+//! [`write!`]: ../../std/macro.write.html
+//! [`format_args!`]: ../../std/macro.format_args.html
+//! [`fmt::Arguments`]: struct.Arguments.html
+//! [`write`]: fn.write.html
+//! [`format`]: fn.format.html
 
 #![stable(feature = "rust1", since = "1.0.0")]
 
@@ -498,10 +521,10 @@ pub use core::fmt::{DebugList, DebugMap, DebugSet, DebugStruct, DebugTuple};
 
 use string;
 
-/// The `format` function takes an `Arguments` struct and returns the resulting
+/// The `format` function takes an [`Arguments`] struct and returns the resulting
 /// formatted string.
 ///
-/// The `Arguments` instance can be created with the `format_args!` macro.
+/// The [`Arguments`] instance can be created with the [`format_args!`] macro.
 ///
 /// # Examples
 ///
@@ -514,15 +537,17 @@ use string;
 /// assert_eq!(s, "Hello, world!");
 /// ```
 ///
-/// Please note that using [`format!`][format!] might be preferrable.
+/// Please note that using [`format!`] might be preferrable.
 /// Example:
 ///
 /// ```
 /// let s = format!("Hello, {}!", "world");
 /// assert_eq!(s, "Hello, world!");
 /// ```
 ///
-/// [format!]: ../macro.format.html
+/// [`Arguments`]: struct.Arguments.html
+/// [`format_args!`]: ../../std/macro.format_args.html
+/// [`format!`]: ../../std/macro.format.html
 #[stable(feature = "rust1", since = "1.0.0")]
 pub fn format(args: Arguments) -> string::String {
     let capacity = args.estimated_capacity();

src/liballoc/string.rs

@@ -653,7 +653,7 @@ impl String {
     /// * `capacity` needs to be the correct value.
     ///
     /// Violating these may cause problems like corrupting the allocator's
-    /// internal datastructures.
+    /// internal data structures.
     ///
     /// The ownership of `ptr` is effectively transferred to the
     /// `String` which may then deallocate, reallocate or change the

src/liballoc/vec.rs

@@ -374,7 +374,7 @@ impl<T> Vec<T> {
     /// * `capacity` needs to be the capacity that the pointer was allocated with.
     ///
     /// Violating these may cause problems like corrupting the allocator's
-    /// internal datastructures. For example it is **not** safe
+    /// internal data structures. For example it is **not** safe
     /// to build a `Vec<u8>` from a pointer to a C `char` array and a `size_t`.
     ///
     /// The ownership of `ptr` is effectively transferred to the

src/libcore/ops/place.rs

@@ -66,7 +66,7 @@ pub trait Place<Data: ?Sized> {
 /// or `Copy`, since the `make_place` method takes `self` by value.
 #[unstable(feature = "placement_new_protocol", issue = "27779")]
 pub trait Placer<Data: ?Sized> {
-    /// `Place` is the intermedate agent guarding the
+    /// `Place` is the intermediate agent guarding the
     /// uninitialized state for `Data`.
     type Place: InPlace<Data>;
 

src/libgraphviz/lib.rs

@@ -548,7 +548,7 @@ impl<'a> LabelText<'a> {
     }
 
     /// Renders text as string suitable for a label in a .dot file.
-    /// This includes quotes or suitable delimeters.
+    /// This includes quotes or suitable delimiters.
     pub fn to_dot_string(&self) -> String {
         match self {
             &LabelStr(ref s) => format!("\"{}\"", s.escape_default()),

src/librustc/hir/intravisit.rs

@@ -87,7 +87,7 @@ pub enum NestedVisitorMap<'this, 'tcx: 'this> {
     /// Do not visit nested item-like things, but visit nested things
     /// that are inside of an item-like.
     ///
-    /// **This is the most common choice.** A very commmon pattern is
+    /// **This is the most common choice.** A very common pattern is
     /// to use `visit_all_item_likes()` as an outer loop,
     /// and to have the visitor that visits the contents of each item
     /// using this setting.

src/librustc/hir/map/mod.rs

@@ -248,7 +248,7 @@ pub struct Map<'hir> {
     pub forest: &'hir Forest,
 
     /// Same as the dep_graph in forest, just available with one fewer
-    /// deref. This is a gratuitious micro-optimization.
+    /// deref. This is a gratuitous micro-optimization.
     pub dep_graph: DepGraph,
 
     /// NodeIds are sequential integers from 0, so we can be

src/librustc/hir/mod.rs

@@ -496,7 +496,7 @@ impl Crate {
         &self.impl_items[&id]
     }
 
-    /// Visits all items in the crate in some determinstic (but
+    /// Visits all items in the crate in some deterministic (but
     /// unspecified) order. If you just need to process every item,
     /// but don't care about nesting, this method is the best choice.
     ///

src/librustc/infer/at.rs

@@ -169,7 +169,7 @@ impl<'a, 'gcx, 'tcx> At<'a, 'gcx, 'tcx> {
     }
 
     /// Sets the "trace" values that will be used for
-    /// error-repporting, but doesn't actually perform any operation
+    /// error-reporting, but doesn't actually perform any operation
     /// yet (this is useful when you want to set the trace using
     /// distinct values from those you wish to operate upon).
     pub fn trace<T>(self,

src/librustc/infer/higher_ranked/mod.rs

@@ -589,7 +589,7 @@ impl<'a, 'gcx, 'tcx> InferCtxt<'a, 'gcx, 'tcx> {
         (result, map)
     }
 
-    /// Searches the region constriants created since `snapshot` was started
+    /// Searches the region constraints created since `snapshot` was started
     /// and checks to determine whether any of the skolemized regions created
     /// in `skol_map` would "escape" -- meaning that they are related to
     /// other regions in some way. If so, the higher-ranked subtyping doesn't

src/librustc/infer/lattice.rs

@@ -46,7 +46,7 @@ pub trait LatticeDir<'f, 'gcx: 'f+'tcx, 'tcx: 'f> : TypeRelation<'f, 'gcx, 'tcx>
     // the LUB/GLB of `a` and `b` as appropriate.
     //
     // Subtle hack: ordering *may* be significant here. This method
-    // relates `v` to `a` first, which may help us to avoid unecessary
+    // relates `v` to `a` first, which may help us to avoid unnecessary
     // type variable obligations. See caller for details.
     fn relate_bound(&mut self, v: Ty<'tcx>, a: Ty<'tcx>, b: Ty<'tcx>) -> RelateResult<'tcx, ()>;
 }

src/librustc/infer/region_inference/mod.rs

@@ -128,7 +128,7 @@ pub enum UndoLogEntry<'tcx> {
     /// We added the given `given`
     AddGiven(Region<'tcx>, ty::RegionVid),
 
-    /// We added a GLB/LUB "combinaton variable"
+    /// We added a GLB/LUB "combination variable"
     AddCombination(CombineMapType, TwoRegions<'tcx>),
 
     /// During skolemization, we sometimes purge entries from the undo