Rollup of 9 pull requests

CONTRIBUTING.md

@@ -84,7 +84,8 @@ feature. We use the 'fork and pull' model described there.
 Please make pull requests against the `master` branch.
 
 All pull requests are reviewed by another person. We have a bot,
-@rust-highfive, that will automatically assign a random person to review your request.
+@rust-highfive, that will automatically assign a random person to review your
+request.
 
 If you want to request that a specific person reviews your pull request,
 you can add an `r?` to the message. For example, Steve usually reviews
@@ -124,6 +125,10 @@ To save @bors some work, and to get small changes through more quickly, when
 the other rollup-eligible patches too, and they'll get tested and merged at
 the same time.
 
+To find documentation-related issues, sort by the [A-docs label][adocs]. 
+
+[adocs]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AA-docs
+
 ## Issue Triage
 
 Sometimes, an issue will stay open, even though the bug has been fixed. And
@@ -132,8 +137,40 @@ meantime.
 
 It can be helpful to go through older bug reports and make sure that they are
 still valid. Load up an older issue, double check that it's still true, and
-leave a comment letting us know if it is or is not. The [least recently updated sort][lru] is good for finding issues like this.
+leave a comment letting us know if it is or is not. The [least recently
+updated sort][lru] is good for finding issues like this.
+
+Contributors with sufficient permissions on the Rust repo can help by adding
+labels to triage issues:
+
+* Yellow, **A**-prefixed labels state which **area** of the project an issue
+  relates to. 
+
+* Magenta, **B**-prefixed labels identify bugs which **belong** elsewhere. 
+
+* Green, **E**-prefixed labels explain the level of **experience** necessary
+  to fix the issue.
+
+* Red, **I**-prefixed labels indicate the **importance** of the issue. The
+  [I-nominated][inom] label indicates that an issue has been nominated for
+  prioritizing at the next triage meeting. 
+
+* Orange, **P**-prefixed labels indicate a bug's **priority**. These labels
+  are only assigned during triage meetings, and replace the [I-nominated][inom]
+  label. 
+
+* Blue, **T**-prefixed bugs denote which **team** the issue belongs to.
+
+* Dark blue, **beta-** labels track changes which need to be backported into
+  the beta branches. 
+
+* The purple **metabug** label marks lists of bugs collected by other
+  categories.  
+
+If you're looking for somewhere to start, check out the [E-easy][eeasy] tag. 
 
+[inom]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-nominated
+[eeasy]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy
 [lru]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
 
 ## Out-of-tree Contributions

src/doc/reference.md

@@ -3255,8 +3255,8 @@ User-defined types have limited capabilities.
 The primitive types are the following:
 
 * The boolean type `bool` with values `true` and `false`.
-* The machine types.
-* The machine-dependent integer and floating-point types.
+* The machine types (integer and floating-point).
+* The machine-dependent integer types.
 
 #### Machine types
 

src/doc/style/errors/ergonomics.md

@@ -63,4 +63,4 @@ for more details.
 ### The `Result`-`impl` pattern [FIXME]
 
 > **[FIXME]** Document the way that the `io` module uses trait impls
-> on `IoResult` to painlessly propagate errors.
+> on `std::io::Result` to painlessly propagate errors.

src/doc/style/features/functions-and-methods/README.md

@@ -20,6 +20,7 @@ for any operation that is clearly associated with a particular
 type.
 
 Methods have numerous advantages over functions:
+
 * They do not need to be imported or qualified to be used: all you
   need is a value of the appropriate type.
 * Their invocation performs autoborrowing (including mutable borrows).

src/doc/style/features/functions-and-methods/input.md

@@ -121,7 +121,7 @@ The primary exception: sometimes a function is meant to modify data
 that the caller already owns, for example to re-use a buffer:
 
 ```rust
-fn read(&mut self, buf: &mut [u8]) -> IoResult<usize>
+fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize>
 ```
 
 (From the [Reader trait](http://static.rust-lang.org/doc/master/std/io/trait.Reader.html#tymethod.read).)
@@ -159,7 +159,7 @@ fn foo(a: u8) { ... }
 Note that
 [`ascii::Ascii`](http://static.rust-lang.org/doc/master/std/ascii/struct.Ascii.html)
 is a _wrapper_ around `u8` that guarantees the highest bit is zero; see
-[newtype patterns]() for more details on creating typesafe wrappers.
+[newtype patterns](../types/newtype.md) for more details on creating typesafe wrappers.
 
 Static enforcement usually comes at little run-time cost: it pushes the
 costs to the boundaries (e.g. when a `u8` is first converted into an

src/doc/style/features/let.md

@@ -34,7 +34,7 @@ Prefer
 
 ```rust
 let foo = match bar {
-    Baz  => 0,
+    Baz => 0,
     Quux => 1
 };
 ```
@@ -44,7 +44,7 @@ over
 ```rust
 let foo;
 match bar {
-    Baz  => {
+    Baz => {
         foo = 0;
     }
     Quux => {
@@ -61,8 +61,8 @@ conditional expression.
 Prefer
 
 ```rust
-s.iter().map(|x| x * 2)
-        .collect::<Vec<_>>()
+let v = s.iter().map(|x| x * 2)
+                .collect::<Vec<_>>();
 ```
 
 over

src/doc/style/ownership/builders.md

@@ -16,7 +16,7 @@ If `T` is such a data structure, consider introducing a `T` _builder_:
    value. When possible, choose a better name: e.g. `Command` is the builder for
    `Process`.
 2. The builder constructor should take as parameters only the data _required_ to
-   to make a `T`.
+   make a `T`.
 3. The builder should offer a suite of convenient methods for configuration,
    including setting up compound inputs (like slices) incrementally.
    These methods should return `self` to allow chaining.
@@ -75,7 +75,7 @@ impl Command {
     }
 
     /// Executes the command as a child process, which is returned.
-    pub fn spawn(&self) -> IoResult<Process> {
+    pub fn spawn(&self) -> std::io::Result<Process> {
         ...
     }
 }

src/doc/trpl/README.md

@@ -15,7 +15,7 @@ language would.
 
 [rust]: http://rust-lang.org
 
-“The Rust Programming Language” is split into seven sections. This introduction
+“The Rust Programming Language” is split into eight sections. This introduction
 is the first. After this:
 
 * [Getting started][gs] - Set up your computer for Rust development.

src/doc/trpl/conditional-compilation.md

@@ -34,7 +34,7 @@ These can nest arbitrarily:
 As for how to enable or disable these switches, if you’re using Cargo,
 they get set in the [`[features]` section][features] of your `Cargo.toml`:
 
-[features]: http://doc.crates.io/manifest.html#the-[features]-section
+[features]: http://doc.crates.io/manifest.html#the-%5Bfeatures%5D-section
 
 ```toml
 [features]

src/doc/trpl/glossary.md

@@ -19,7 +19,7 @@ In the example above `x` and `y` have arity 2. `z` has arity 3.
 
 When a compiler is compiling your program, it does a number of different
 things. One of the things that it does is turn the text of your program into an
-‘abstract syntax tree’, or‘AST’. This tree is a representation of the
+‘abstract syntax tree’, or ‘AST’. This tree is a representation of the
 structure of your program. For example, `2 + 3` can be turned into a tree:
 
 ```text

src/doc/trpl/lifetimes.md

@@ -134,8 +134,29 @@ x: &'a i32,
 # }
 ```
 
-uses it. So why do we need a lifetime here? We need to ensure that any
-reference to the contained `i32` does not outlive the containing `Foo`.
+uses it. So why do we need a lifetime here? We need to ensure that any reference
+to a `Foo` cannot outlive the reference to an `i32` it contains.
+
+If you have multiple references, you can use the same lifetime multiple times:
+
+```rust
+fn x_or_y<'a>(x: &'a str, y: &'a str) -> &'a str {
+#    x
+# }
+```
+
+This says that `x` and `y` both are alive for the same scope, and that the
+return value is also alive for that scope. If you wanted `x` and `y` to have
+different lifetimes, you can use multiple lifetime parameters:
+
+```rust
+fn x_or_y<'a, 'b>(x: &'a str, y: &'b str) -> &'a str {
+#    x
+# }
+```
+
+In this example, `x` and `y` have different valid scopes, but the return value
+has the same lifetime as `x`.
 
 ## Thinking in scopes
 

src/doc/trpl/method-syntax.md

@@ -4,7 +4,7 @@ Functions are great, but if you want to call a bunch of them on some data, it
 can be awkward. Consider this code:
 
 ```rust,ignore
-baz(bar(foo)));
+baz(bar(foo));
 ```
 
 We would read this left-to right, and so we see ‘baz bar foo’. But this isn’t the

src/doc/trpl/traits.md

@@ -285,7 +285,7 @@ fn bar<T, K>(x: T, y: K) where T: Clone, K: Clone + Debug {
 
 fn main() {
     foo("Hello", "world");
-    bar("Hello", "workd");
+    bar("Hello", "world");
 }
 ```
 

src/libcollections/binary_heap.rs

@@ -153,7 +153,7 @@
 use core::prelude::*;
 
 use core::iter::{FromIterator};
-use core::mem::{zeroed, replace, swap};
+use core::mem::swap;
 use core::ptr;
 
 use slice;
@@ -484,46 +484,42 @@ impl<T: Ord> BinaryHeap<T> {
 
     // The implementations of sift_up and sift_down use unsafe blocks in
     // order to move an element out of the vector (leaving behind a
-    // zeroed element), shift along the others and move it back into the
-    // vector over the junk element. This reduces the constant factor
-    // compared to using swaps, which involves twice as many moves.
-    fn sift_up(&mut self, start: usize, mut pos: usize) {
+    // hole), shift along the others and move the removed element back into the
+    // vector at the final location of the hole.
+    // The `Hole` type is used to represent this, and make sure
+    // the hole is filled back at the end of its scope, even on panic.
+    // Using a hole reduces the constant factor compared to using swaps,
+    // which involves twice as many moves.
+    fn sift_up(&mut self, start: usize, pos: usize) {
         unsafe {
-            let new = replace(&mut self.data[pos], zeroed());
+            // Take out the value at `pos` and create a hole.
+            let mut hole = Hole::new(&mut self.data, pos);
 
-            while pos > start {
-                let parent = (pos - 1) >> 1;
-
-                if new <= self.data[parent] { break; }
-
-                let x = replace(&mut self.data[parent], zeroed());
-                ptr::write(&mut self.data[pos], x);
-                pos = parent;
+            while hole.pos() > start {
+                let parent = (hole.pos() - 1) / 2;
+                if hole.removed() <= hole.get(parent) { break }
+                hole.move_to(parent);
             }
-            ptr::write(&mut self.data[pos], new);
         }
     }
 
     fn sift_down_range(&mut self, mut pos: usize, end: usize) {
+        let start = pos;
         unsafe {
-            let start = pos;
-            let new = replace(&mut self.data[pos], zeroed());
-
+            let mut hole = Hole::new(&mut self.data, pos);
             let mut child = 2 * pos + 1;
             while child < end {
                 let right = child + 1;
-                if right < end && !(self.data[child] > self.data[right]) {
+                if right < end && !(hole.get(child) > hole.get(right)) {
                     child = right;
                 }
-                let x = replace(&mut self.data[child], zeroed());
-                ptr::write(&mut self.data[pos], x);
-                pos = child;
-                child = 2 * pos + 1;
+                hole.move_to(child);
+                child = 2 * hole.pos() + 1;
             }
 
-            ptr::write(&mut self.data[pos], new);
-            self.sift_up(start, pos);
+            pos = hole.pos;
         }
+        self.sift_up(start, pos);
     }
 
     fn sift_down(&mut self, pos: usize) {
@@ -554,6 +550,73 @@ impl<T: Ord> BinaryHeap<T> {
     pub fn clear(&mut self) { self.drain(); }
 }
 
+/// Hole represents a hole in a slice i.e. an index without valid value
+/// (because it was moved from or duplicated).
+/// In drop, `Hole` will restore the slice by filling the hole
+/// position with the value that was originally removed.
+struct Hole<'a, T: 'a> {
+    data: &'a mut [T],
+    /// `elt` is always `Some` from new until drop.
+    elt: Option<T>,
+    pos: usize,
+}
+
+impl<'a, T> Hole<'a, T> {
+    /// Create a new Hole at index `pos`.
+    fn new(data: &'a mut [T], pos: usize) -> Self {
+        unsafe {
+            let elt = ptr::read(&data[pos]);
+            Hole {
+                data: data,
+                elt: Some(elt),
+                pos: pos,
+            }
+        }
+    }
+
+    #[inline(always)]
+    fn pos(&self) -> usize { self.pos }
+
+    /// Return a reference to the element removed
+    #[inline(always)]
+    fn removed(&self) -> &T {
+        self.elt.as_ref().unwrap()
+    }
+
+    /// Return a reference to the element at `index`.
+    ///
+    /// Panics if the index is out of bounds.
+    ///
+    /// Unsafe because index must not equal pos.
+    #[inline(always)]
+    unsafe fn get(&self, index: usize) -> &T {
+        debug_assert!(index != self.pos);
+        &self.data[index]
+    }
+
+    /// Move hole to new location
+    ///
+    /// Unsafe because index must not equal pos.
+    #[inline(always)]
+    unsafe fn move_to(&mut self, index: usize) {
+        debug_assert!(index != self.pos);
+        let index_ptr: *const _ = &self.data[index];
+        let hole_ptr = &mut self.data[self.pos];
+        ptr::copy_nonoverlapping(index_ptr, hole_ptr, 1);
+        self.pos = index;
+    }
+}
+
+impl<'a, T> Drop for Hole<'a, T> {
+    fn drop(&mut self) {
+        // fill the hole again
+        unsafe {
+            let pos = self.pos;
+            ptr::write(&mut self.data[pos], self.elt.take().unwrap());
+        }
+    }
+}
+
 /// `BinaryHeap` iterator.
 #[stable(feature = "rust1", since = "1.0.0")]
 pub struct Iter <'a, T: 'a> {

src/libcollections/fmt.rs

@@ -164,8 +164,8 @@
 //! provides some helper methods.
 //!
 //! Additionally, the return value of this function is `fmt::Result` which is a
-//! typedef to `Result<(), IoError>` (also known as `IoResult<()>`). Formatting
-//! implementations should ensure that they return errors from `write!`
+//! typedef to `Result<(), std::io::Error>` (also known as `std::io::Result<()>`).
+//! Formatting implementations should ensure that they return errors from `write!`
 //! correctly (propagating errors upward).
 //!
 //! An example of implementing the formatting traits would look