Fix some typos.

src/doc/nomicon/destructors.md

@@ -17,7 +17,7 @@ boilerplate" to drop children. If a struct has no special logic for being
 dropped other than dropping its children, then it means `Drop` doesn't need to
 be implemented at all!
 
-**There is no stable way to prevent this behaviour in Rust 1.0.**
+**There is no stable way to prevent this behavior in Rust 1.0.**
 
 Note that taking `&mut self` means that even if you could suppress recursive
 Drop, Rust will prevent you from e.g. moving fields out of self. For most types,
@@ -101,7 +101,7 @@ After we deallocate the `box`'s ptr in SuperBox's destructor, Rust will
 happily proceed to tell the box to Drop itself and everything will blow up with
 use-after-frees and double-frees.
 
-Note that the recursive drop behaviour applies to all structs and enums
+Note that the recursive drop behavior applies to all structs and enums
 regardless of whether they implement Drop. Therefore something like
 
 ```rust

src/doc/nomicon/drop-flags.md

@@ -40,7 +40,7 @@ y = x;                   // y was init; Drop y, overwrite it, and make x uninit!
                          // x goes out of scope; x was uninit; do nothing.
 ```
 
-Similarly, branched code where all branches have the same behaviour with respect
+Similarly, branched code where all branches have the same behavior with respect
 to initialization has static drop semantics:
 
 ```rust

src/doc/nomicon/leaking.md

@@ -93,13 +93,13 @@ println!("{}", vec[0]);
 This is pretty clearly Not Good. Unfortunately, we're kind've stuck between a
 rock and a hard place: maintaining consistent state at every step has an
 enormous cost (and would negate any benefits of the API). Failing to maintain
-consistent state gives us Undefined Behaviour in safe code (making the API
+consistent state gives us Undefined Behavior in safe code (making the API
 unsound).
 
 So what can we do? Well, we can pick a trivially consistent state: set the Vec's
 len to be 0 when we start the iteration, and fix it up if necessary in the
 destructor. That way, if everything executes like normal we get the desired
-behaviour with minimal overhead. But if someone has the *audacity* to
+behavior with minimal overhead. But if someone has the *audacity* to
 mem::forget us in the middle of the iteration, all that does is *leak even more*
 (and possibly leave the Vec in an unexpected but otherwise consistent state).
 Since we've accepted that mem::forget is safe, this is definitely safe. We call

src/doc/nomicon/other-reprs.md

@@ -19,8 +19,8 @@ kept in mind. Due to its dual purpose as "for FFI" and "for layout control",
 `repr(C)` can be applied to types that will be nonsensical or problematic if
 passed through the FFI boundary.
 
-* ZSTs are still zero-sized, even though this is not a standard behaviour in
-C, and is explicitly contrary to the behaviour of an empty type in C++, which
+* ZSTs are still zero-sized, even though this is not a standard behavior in
+C, and is explicitly contrary to the behavior of an empty type in C++, which
 still consumes a byte of space.
 
 * DSTs, tuples, and tagged unions are not a concept in C and as such are never
@@ -65,7 +65,7 @@ compiler might be able to paper over alignment issues with shifts and masks.
 However if you take a reference to a packed field, it's unlikely that the
 compiler will be able to emit code to avoid an unaligned load.
 
-**[As of Rust 1.0 this can cause undefined behaviour.][ub loads]**
+**[As of Rust 1.0 this can cause undefined behavior.][ub loads]**
 
 `repr(packed)` is not to be used lightly. Unless you have extreme requirements,
 this should not be used.

src/doc/nomicon/repr-rust.md

@@ -6,7 +6,7 @@ value of alignment `n` must only be stored at an address that is a multiple of
 `n`. So alignment 2 means you must be stored at an even address, and 1 means
 that you can be stored anywhere. Alignment is at least 1, and always a power of
 2. Most primitives are generally aligned to their size, although this is
-platform-specific behaviour. In particular, on x86 `u64` and `f64` may be only
+platform-specific behavior. In particular, on x86 `u64` and `f64` may be only
 aligned to 32 bits.
 
 A type's size must always be a multiple of its alignment. This ensures that an

src/doc/nomicon/vec-zsts.md

@@ -5,7 +5,7 @@ It's time. We're going to fight the spectre that is zero-sized types. Safe Rust
 raw allocations, which are exactly the two things that care about
 zero-sized types. We need to be careful of two things:
 
-* The raw allocator API has undefined behaviour if you pass in 0 for an
+* The raw allocator API has undefined behavior if you pass in 0 for an
   allocation size.
 * raw pointer offsets are no-ops for zero-sized types, which will break our
   C-style pointer iterator.

src/librustc/middle/free_region.rs

@@ -10,7 +10,7 @@
 
 //! This file handles the relationships between free regions --
 //! meaning lifetime parameters. Ordinarily, free regions are
-//! unrelated to one another, but they can be related vai implied or
+//! unrelated to one another, but they can be related via implied or
 //! explicit bounds.  In that case, we track the bounds using the
 //! `TransitiveRelation` type and use that to decide when one free
 //! region outlives another and so forth.

src/librustc_mir/hair.rs

@@ -56,7 +56,7 @@ pub trait Hair: Sized+Debug+Clone+Eq+Hash { // (*)
     /// Returns the type `usize`.
     fn usize_ty(&mut self) -> Self::Ty;
 
-    /// Returns the literal for `true`
+    /// Returns the literal for `value` as a `usize`.
     fn usize_literal(&mut self, value: usize) -> Literal<Self>;
 
     /// Returns the type `bool`.
@@ -65,7 +65,7 @@ pub trait Hair: Sized+Debug+Clone+Eq+Hash { // (*)
     /// Returns the literal for `true`
     fn true_literal(&mut self) -> Literal<Self>;
 
-    /// Returns the literal for `true`
+    /// Returns the literal for `false`
     fn false_literal(&mut self) -> Literal<Self>;
 
     /// Returns a reference to `PartialEq::<T,T>::eq`

src/librustc_typeck/diagnostics.rs

@@ -1819,7 +1819,7 @@ fn bar(foo: Foo) -> u32 {
 }
 ```
 
-Try using `{}` isntead:
+Try using `{}` instead:
 
 ```
 fn bar(foo: Foo) -> u32 {
@@ -2010,8 +2010,8 @@ wrapped type `T` implements `Clone`. The `where` clause is important because
 some types will not implement `Clone`, and thus will not get this method.
 
 In our erroneous example, however, we're referencing a single concrete type.
-Since we know for certain that Wrapper<u32> implements Clone, there's no reason
-to also specify it in a `where` clause.
+Since we know for certain that `Wrapper<u32>` implements `Clone`, there's no
+reason to also specify it in a `where` clause.
 "##,
 
 E0194: r##"
@@ -2581,7 +2581,7 @@ In this example, we're attempting to take a type of `Foo::Bar` in the
 do_something function. This is not legal: `Foo::Bar` is a value of type `Foo`,
 not a distinct static type. Likewise, it's not legal to attempt to
 `impl Foo::Bar`: instead, you must `impl Foo` and then pattern match to specify
-behaviour for specific enum variants.
+behavior for specific enum variants.
 "##,
 
 E0249: r##"