Fix several tiny typos

Author: iblech

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/match.md

@@ -23,7 +23,7 @@ match x {
 `match` takes an expression and then branches based on its value. Each *arm* of
 the branch is of the form `val => expression`. When the value matches, that arm's
 expression will be evaluated. It's called `match` because of the term 'pattern
-matching', which `match` is an implementation of.
+matching,' which `match` is an implementation of.
 
 So what's the big advantage here? Well, there are a few. First of all, `match`
 enforces *exhaustiveness checking*. Do you see that last arm, the one with the

src/doc/trpl/method-syntax.md

@@ -61,7 +61,7 @@ multiplications later, and we have our area.
 ## Chaining method calls
 
 So, now we know how to call a method, such as `foo.bar()`. But what about our
-original example, `foo.bar().baz()`? This is called 'method chaining', and we
+original example, `foo.bar().baz()`? This is called 'method chaining,' and we
 can do it by returning `self`.
 
 ```

src/doc/trpl/more-strings.md

@@ -14,7 +14,7 @@ Rust has two main types of strings: `&str` and `String`.
 
 # &str
 
-The first kind is a `&str`. This is pronounced a 'string slice'.
+The first kind is a `&str`. This is pronounced a 'string slice.'
 String literals are of the type `&str`:
 
 ```

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,15 +412,15 @@ 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:
 
 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.
 
@@ -649,7 +649,7 @@ 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".
+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

@@ -2348,7 +2348,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,
@@ -2359,7 +2359,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}
 }