Merge pull request #422 from ehuss/spell

Fix a few spelling errors.

src/attributes.md

@@ -74,7 +74,7 @@ type int8_t = i8;
 // Outer attribute applies to the entire function.
 fn some_unused_variables() {
   #![allow(unused_variables)]
-  
+
   let x = ();
   let y = ();
   let z = ();
@@ -90,7 +90,7 @@ There are three kinds of attributes:
 ## Active and inert attributes
 
 An attribute is either active or inert. During attribute processing, *active
-attributes* remove themselves from the thing they are on while *inert attriutes*
+attributes* remove themselves from the thing they are on while *inert attributes*
 stay on.
 
 The `cfg` and `cfg_attr` attributes are active. The `test` attribute is inert
@@ -472,7 +472,7 @@ function for a trait implementation and not to all trait implementations.
 
 > ***Note***: The compiler automatically inlines functions based on internal
 > heuristics. Incorrectly inlining functions can actually make the program
-> slower, so this attibute should be used with care.
+> slower, so this attribute should be used with care.
 
 There are three ways of using the inline attribute:
 

src/introduction.md

@@ -77,7 +77,7 @@ information. These conventions are documented here.
   term is used outside of that chapter, it is usually a link to the section that
   has this definition.
 
-  An *example term* is an example of a term beind defined.
+  An *example term* is an example of a term being defined.
 
 * Notes that contain useful information about the state of the book or point out
   useful, but mostly out of scope, information are in blockquotes that start

src/procedural-macros.md

@@ -15,7 +15,7 @@ Procedural macros must be defined in a crate with the [crate type] of
 `proc-macro`.
 
 > **Note**: When using Cargo, Procedural macro crates are defined with the
-> `proc-macro` key in your manfiest:
+> `proc-macro` key in your manifest:
 >
 > ```toml
 > [lib]

src/tokens.md

@@ -524,7 +524,7 @@ usages and meanings are defined in the linked pages.
 | `%`    | Percent     | [Remainder][arith]
 | `^`    | Caret       | [Bitwise and Logical XOR][arith]
 | `!`    | Not         | [Bitwise and Logical NOT][negation], [Macro Calls][macros], [Inner Attributes][attributes], [Never Type]
-| `&`    | And         | [Bitwise and Logcal AND][arith], [Borrow], [References]
+| `&`    | And         | [Bitwise and Logical AND][arith], [Borrow], [References]
 | <code>\|</code> | Or | [Bitwise and Logical OR][arith], [Closures], [Match]
 | `&&`   | AndAnd      | [Lazy AND][lazy-bool], [Borrow], [References]
 | <code>\|\|</code> | OrOr | [Lazy OR][lazy-bool], [Closures]

src/type-layout.md

@@ -144,7 +144,7 @@ There are no guarantees of data layout made by this representation.
 ### The `C` Representation
 
 The `C` representation is designed for dual purposes. One purpose is for
-creating types that are interoptable with the C Language. The second purpose is
+creating types that are interoperable with the C Language. The second purpose is
 to create types that you can soundly performing operations that rely on data
 layout such as reinterpreting values as a different type.