Rollup of 10 pull requests

src/doc/style/style/comments.md

@@ -85,3 +85,20 @@ Use inner doc comments _only_ to document crates and file-level modules:
 //!
 //! The core library is a something something...
 ```
+
+### Explain context.
+
+Rust doesn't have special constructors, only functions that return new
+instances.  These aren't visible in the automatically generated documentation
+for a type, so you should specifically link to them:
+
+``` rust
+/// An iterator that yields `None` forever after the underlying iterator
+/// yields `None` once.
+///
+/// These can be created through
+/// [`iter.fuse()`](trait.Iterator.html#method.fuse).
+pub struct Fuse<I> {
+    // ...
+}
+```

src/doc/trpl/advanced-linking.md

@@ -26,7 +26,7 @@ shells out to the system linker (`gcc` on most systems, `link.exe` on MSVC),
 so it makes sense to provide extra command line
 arguments, but this will not always be the case. In the future `rustc` may use
 LLVM directly to link native libraries, in which case `link_args` will have no
-meaning. You can achieve the same effect as the `link-args` attribute with the
+meaning. You can achieve the same effect as the `link_args` attribute with the
 `-C link-args` argument to `rustc`.
 
 It is highly recommended to *not* use this attribute, and rather use the more
@@ -71,7 +71,7 @@ Dynamic linking on Linux can be undesirable if you wish to use new library
 features on old systems or target systems which do not have the required
 dependencies for your program to run.
 
-Static linking is supported via an alternative `libc`, `musl`. You can compile
+Static linking is supported via an alternative `libc`, [`musl`](http://www.musl-libc.org). You can compile
 your own version of Rust with `musl` enabled and install it into a custom
 directory with the instructions below:
 

src/doc/trpl/closures.md

@@ -1,9 +1,10 @@
 % Closures
 
-Rust not only has named functions, but anonymous functions as well. Anonymous
-functions that have an associated environment are called ‘closures’, because they
-close over an environment. Rust has a really great implementation of them, as
-we’ll see.
+Sometimes it is useful to wrap up a function and _free variables_ for better
+clarity and reuse. The free variables that can be used come from the
+enclosing scope and are ‘closed over’ when used in the function. From this, we
+get the name ‘closures’ and Rust provides a really great implementation of
+them, as we’ll see.
 
 # Syntax
 
@@ -34,7 +35,7 @@ assert_eq!(4, plus_two(2));
 ```
 
 You’ll notice a few things about closures that are a bit different from regular
-functions defined with `fn`. The first is that we did not need to
+named functions defined with `fn`. The first is that we did not need to
 annotate the types of arguments the closure takes or the values it returns. We
 can:
 
@@ -44,14 +45,15 @@ let plus_one = |x: i32| -> i32 { x + 1 };
 assert_eq!(2, plus_one(1));
 ```
 
-But we don’t have to. Why is this? Basically, it was chosen for ergonomic reasons.
-While specifying the full type for named functions is helpful with things like
-documentation and type inference, the types of closures are rarely documented
-since they’re anonymous, and they don’t cause the kinds of error-at-a-distance
-problems that inferring named function types can.
+But we don’t have to. Why is this? Basically, it was chosen for ergonomic
+reasons. While specifying the full type for named functions is helpful with
+things like documentation and type inference, the full type signatures of
+closures are rarely documented since they’re anonymous, and they don’t cause
+the kinds of error-at-a-distance problems that inferring named function types
+can.
 
-The second is that the syntax is similar, but a bit different. I’ve added spaces
-here for easier comparison:
+The second is that the syntax is similar, but a bit different. I’ve added
+spaces here for easier comparison:
 
 ```rust
 fn  plus_one_v1   (x: i32) -> i32 { x + 1 }
@@ -63,8 +65,8 @@ Small differences, but they’re similar.
 
 # Closures and their environment
 
-Closures are called such because they ‘close over their environment’. It
-looks like this:
+The environment for a closure can include bindings from its enclosing scope in
+addition to parameters and local bindings. It looks like this:
 
 ```rust
 let num = 5;
@@ -197,9 +199,10 @@ frame.  Without `move`, a closure may be tied to the stack frame that created
 it, while a `move` closure is self-contained. This means that you cannot
 generally return a non-`move` closure from a function, for example.
 
-But before we talk about taking and returning closures, we should talk some more
-about the way that closures are implemented. As a systems language, Rust gives
-you tons of control over what your code does, and closures are no different.
+But before we talk about taking and returning closures, we should talk some
+more about the way that closures are implemented. As a systems language, Rust
+gives you tons of control over what your code does, and closures are no
+different.
 
 # Closure implementation
 
@@ -288,9 +291,9 @@ isn’t interesting. The next part is:
 #   some_closure(1) }
 ```
 
-Because `Fn` is a trait, we can bound our generic with it. In this case, our closure
-takes a `i32` as an argument and returns an `i32`, and so the generic bound we use
-is `Fn(i32) -> i32`.
+Because `Fn` is a trait, we can bound our generic with it. In this case, our
+closure takes a `i32` as an argument and returns an `i32`, and so the generic
+bound we use is `Fn(i32) -> i32`.
 
 There’s one other key point here: because we’re bounding a generic with a
 trait, this will get monomorphized, and therefore, we’ll be doing static
@@ -452,7 +455,7 @@ autogenerated name.
 The error also points out that the return type is expected to be a reference,
 but what we are trying to return is not. Further, we cannot directly assign a
 `'static` lifetime to an object. So we'll take a different approach and return
-a "trait object" by `Box`ing up the `Fn`. This _almost_ works:
+a ‘trait object’ by `Box`ing up the `Fn`. This _almost_ works:
 
 ```rust,ignore
 fn factory() -> Box<Fn(i32) -> i32> {

src/doc/trpl/crates-and-modules.md

@@ -563,8 +563,8 @@ What's going on here?
 First, both `extern crate` and `use` allow renaming the thing that is being
 imported. So the crate is still called "phrases", but here we will refer
 to it as "sayings". Similarly, the first `use` statement pulls in the
-`japanese::farewells` module from the crate, but makes it available as
-`jp_farewells` as opposed to simply `farewells`. This can help to avoid
+`japanese::greetings` module from the crate, but makes it available as
+`ja_greetings` as opposed to simply `greetings`. This can help to avoid
 ambiguity when importing similarly-named items from different places.
 
 The second `use` statement uses a star glob to bring in _all_ symbols from the

src/doc/trpl/iterators.md

@@ -42,12 +42,12 @@ loop is just a handy way to write this `loop`/`match`/`break` construct.
 `for` loops aren't the only thing that uses iterators, however. Writing your
 own iterator involves implementing the `Iterator` trait. While doing that is
 outside of the scope of this guide, Rust provides a number of useful iterators
-to accomplish various tasks. Before we talk about those, we should talk about a
-Rust anti-pattern. And that's using ranges like this.
+to accomplish various tasks. But first, a few notes about limitations of ranges.
 
-Yes, we just talked about how ranges are cool. But ranges are also very
-primitive. For example, if you needed to iterate over the contents of a vector,
-you may be tempted to write this:
+Ranges are very primitive, and we often can use better alternatives. Consider
+following Rust anti-pattern: using ranges to emulate a C-style `for` loop. Let’s
+suppose you needed to iterate over the contents of a vector. You may be tempted
+to write this:
 
 ```rust
 let nums = vec![1, 2, 3];
@@ -281,8 +281,8 @@ If you are trying to execute a closure on an iterator for its side effects,
 just use `for` instead.
 
 There are tons of interesting iterator adapters. `take(n)` will return an
-iterator over the next `n` elements of the original iterator. Let's try it out with our infinite
-iterator from before:
+iterator over the next `n` elements of the original iterator. Let's try it out
+with an infinite iterator:
 
 ```rust
 for i in (1..).take(5) {

src/doc/trpl/lifetimes.md

@@ -43,11 +43,11 @@ With that in mind, let’s learn about lifetimes.
 Lending out a reference to a resource that someone else owns can be
 complicated. For example, imagine this set of operations:
 
-- I acquire a handle to some kind of resource.
-- I lend you a reference to the resource.
-- I decide I’m done with the resource, and deallocate it, while you still have
+1. I acquire a handle to some kind of resource.
+2. I lend you a reference to the resource.
+3. I decide I’m done with the resource, and deallocate it, while you still have
   your reference.
-- You decide to use the resource.
+4. You decide to use the resource.
 
 Uh oh! Your reference is pointing to an invalid resource. This is called a
 dangling pointer or ‘use after free’, when the resource is memory.

src/doc/trpl/patterns.md

@@ -299,7 +299,7 @@ match x {
 ```
 
 This prints `no`, because the `if` applies to the whole of `4 | 5`, and not to
-just the `5`, In other words, the the precedence of `if` behaves like this:
+just the `5`. In other words, the precedence of `if` behaves like this:
 
 ```text
 (4 | 5) if y => ...

src/libcore/option.rs

@@ -706,7 +706,8 @@ impl<T> Option<T> {
 }
 
 impl<'a, T: Clone> Option<&'a T> {
-    /// Maps an Option<&T> to an Option<T> by cloning the contents of the Option.
+    /// Maps an `Option<&T>` to an `Option<T>` by cloning the contents of the
+    /// option.
     #[stable(feature = "rust1", since = "1.0.0")]
     pub fn cloned(self) -> Option<T> {
         self.map(|t| t.clone())

src/librustc_trans/diagnostics.rs

@@ -12,6 +12,21 @@
 
 register_long_diagnostics! {
 
+E0515: r##"
+A constant index expression was out of bounds. Erroneous code example:
+
+```
+let x = &[0, 1, 2][7]; // error: const index-expr is out of bounds
+```
+
+Please specify a valid index (not inferior to 0 or superior to array length).
+Example:
+
+```
+let x = &[0, 1, 2][2]; // ok!
+```
+"##,
+
 }
 
 register_diagnostics! {

src/librustc_trans/trans/consts.rs

@@ -628,8 +628,8 @@ fn const_expr_unadjusted<'a, 'tcx>(cx: &CrateContext<'a, 'tcx>,
             if iv >= len {
                 // FIXME #3170: report this earlier on in the const-eval
                 // pass. Reporting here is a bit late.
-                cx.sess().span_err(e.span,
-                                   "const index-expr is out of bounds");
+                span_err!(cx.sess(), e.span, E0515,
+                          "const index-expr is out of bounds");
                 C_undef(val_ty(arr).element_type())
             } else {
                 const_get_elt(cx, arr, &[iv as c_uint])

src/test/run-pass/lexer-crlf-line-endings-string-literal-doc-comment.rs

@@ -1,7 +1,7 @@
 // ignore-tidy-cr ignore-license
 // ignore-tidy-cr (repeated again because of tidy bug)
 // license is ignored because tidy can't handle the CRLF here properly.
-
+
 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
 // file at the top-level directory of this distribution and at
 // http://rust-lang.org/COPYRIGHT.
@@ -11,33 +11,33 @@
 // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
-
+
 // NB: this file needs CRLF line endings. The .gitattributes file in
 // this directory should enforce it.
-
+
 // ignore-pretty
-
+
 /// Doc comment that ends in CRLF
 pub fn foo() {}
-
+
 /** Block doc comment that
  *  contains CRLF characters
  */
 pub fn bar() {}
-
+
 fn main() {
     let s = "string
 literal";
     assert_eq!(s, "string\nliteral");
-
+
     let s = "literal with \
              escaped newline";
     assert_eq!(s, "literal with escaped newline");
-
+
     let s = r"string
 literal";
     assert_eq!(s, "string\nliteral");
-
+
     // validate that our source file has CRLF endings
     let source = include_str!("lexer-crlf-line-endings-string-literal-doc-comment.rs");
     assert!(source.contains("string\r\nliteral"));