Rollup merge of #22027 - iblech:patch-1, r=steveklabnik

The first commit adds a short note which I believe will reduce worries in people who work with closures very often and read the Rust book for their first time.

The second commit consists solely of tiny typo fixes. In some cases, I changed "logical" quotations like

    She said, "I like programming".

to

    She said, "I like programming."

because the latter seems to be the prevalent style in the book.

src/doc/trpl/documentation.md

@@ -15,7 +15,7 @@ comments":
 // the "link" crate attribute is currently required for rustdoc, but normally
 // isn't needed.
 #![crate_id = "universe"]
-#![crate_type="lib"]
+#![crate_type= lib"]
 
 //! Tools for dealing with universes (this is a doc comment, and is shown on
 //! the crate index page. The ! makes it apply to the parent of the comment,

src/doc/trpl/macros.md

@@ -163,7 +163,7 @@ The syntax `$(...)*` on the left-hand side of the `=>` in a macro definition
 accepts zero or more occurrences of its contents. It works much
 like the `*` operator in regular expressions. It also supports a
 separator token (a comma-separated list could be written `$(...),*`), and `+`
-instead of `*` to mean "at least one".
+instead of `*` to mean "at least one."
 
 ~~~~
 # enum T { SpecialA(u32), SpecialB(u32), SpecialC(u32), SpecialD(u32) }
@@ -195,7 +195,7 @@ As the above example demonstrates, `$(...)*` is also valid on the right-hand
 side of a macro definition. The behavior of `*` in transcription,
 especially in cases where multiple `*`s are nested, and multiple different
 names are involved, can seem somewhat magical and unintuitive at first. The
-system that interprets them is called "Macro By Example". The two rules to
+system that interprets them is called "Macro By Example." The two rules to
 keep in mind are (1) the behavior of `$(...)*` is to walk through one "layer"
 of repetitions for all of the `$name`s it contains in lockstep, and (2) each
 `$name` must be under at least as many `$(...)*`s as it was matched against.
@@ -309,7 +309,7 @@ there is a solution.
 
 A macro may accept multiple different input grammars. The first one to
 successfully match the actual argument to a macro invocation is the one that
-"wins".
+"wins."
 
 In the case of the example above, we want to write a recursive macro to
 process the semicolon-terminated lines, one-by-one. So, we want the following

src/doc/trpl/ownership.md

@@ -293,7 +293,7 @@ struct Foo<'a> {
 }
 
 fn main() {
-    let y = &5; // this is the same as `let _y = 5; let y = &_y;
+    let y = &5; // this is the same as `let _y = 5; let y = &_y;`
     let f = Foo { x: y };
 
     println!("{}", f.x);

src/doc/trpl/unsafe.md

@@ -308,7 +308,7 @@ crate to allow) and of course requires an `unsafe` block.
 ## Assembly template
 
 The `assembly template` is the only required parameter and must be a
-literal string (i.e `""`)
+literal string (i.e. `""`)
 
 ```
 #![feature(asm)]
@@ -412,7 +412,7 @@ memory, `memory` should also be specified.
 ## Options
 
 The last section, `options` is specific to Rust. The format is comma
-separated literal strings (i.e `:"foo", "bar", "baz"`). It's used to
+separated literal strings (i.e. `:"foo", "bar", "baz"`). It's used to
 specify some extra info about the inline assembly:
 
 Current valid options are:
@@ -420,7 +420,7 @@ Current valid options are:
 1. *volatile* - specifying this is analogous to
    `__asm__ __volatile__ (...)` in gcc/clang.
 2. *alignstack* - certain instructions expect the stack to be
-   aligned a certain way (i.e SSE) and specifying this indicates to
+   aligned a certain way (i.e. SSE) and specifying this indicates to
    the compiler to insert its usual stack alignment code
 3. *intel* - use intel syntax instead of the default AT&T.
 
@@ -646,8 +646,8 @@ The `rustc` compiler has certain pluggable operations, that is,
 functionality that isn't hard-coded into the language, but is
 implemented in libraries, with a special marker to tell the compiler
 it exists. The marker is the attribute `#[lang="..."]` and there are
-various different values of `...`, i.e. various different "lang
-items".
+various different values of `...`, i.e. various different 'lang
+items'.
 
 For example, `Box` pointers require two lang items, one for allocation
 and one for deallocation. A freestanding program that uses the `Box`

src/libcore/iter.rs

@@ -2374,7 +2374,7 @@ impl<A, St, F> Iterator for Unfold<St, F> where F: FnMut(&mut St) -> Option<A> {
 /// iteration
 #[derive(Clone)]
 #[unstable(feature = "core",
-           reason = "may be renamed or replaced by range notation adapaters")]
+           reason = "may be renamed or replaced by range notation adapters")]
 pub struct Counter<A> {
     /// The current state the counter is at (next value to be yielded)
     state: A,
@@ -2385,7 +2385,7 @@ pub struct Counter<A> {
 /// Creates a new counter with the specified start/step
 #[inline]
 #[unstable(feature = "core",
-           reason = "may be renamed or replaced by range notation adapaters")]
+           reason = "may be renamed or replaced by range notation adapters")]
 pub fn count<A>(start: A, step: A) -> Counter<A> {
     Counter{state: start, step: step}
 }