Minor language fixes (#364)

src/destructors.md

@@ -120,7 +120,7 @@ Next variant.
 
 In general this works really nicely because you don't need to worry about
 adding/removing drops when you refactor your data layout. Still there's
-certainly many valid usecases for needing to do trickier things with
+certainly many valid use cases for needing to do trickier things with
 destructors.
 
 The classic safe solution to overriding recursive drop and allowing moving out

src/exotic-sizes.md

@@ -157,9 +157,9 @@ because that wouldn't make sense.
 We recommend against modelling C's `void*` type with `*const Void`.
 A lot of people started doing that but quickly ran into trouble because
 Rust doesn't really have any safety guards against trying to instantiate
-empty types with unsafe code, and if you do it, it's Undefined Behaviour.
+empty types with unsafe code, and if you do it, it's Undefined Behavior.
 This was especially problematic because developers had a habit of converting
-raw pointers to references and `&Void` is *also* Undefined Behaviour to
+raw pointers to references and `&Void` is *also* Undefined Behavior to
 construct.
 
 `*const ()` (or equivalent) works reasonably well for `void*`, and can be made

src/intro.md

@@ -32,7 +32,7 @@ Where The Reference exists to detail the syntax and semantics of every part of t
 
 The Reference will tell you the syntax and semantics of references, destructors, and unwinding, but it won't tell you how combining them can lead to exception-safety issues, or how to deal with those issues.
 
-It should be noted that we haven't synced The Rustnomicon and The Reference well, so they may have a duplicate content.
+It should be noted that we haven't synced The Rustnomicon and The Reference well, so they may have duplicate content.
 In general, if the two documents disagree, The Reference should be assumed to be correct (it isn't yet considered normative, it's just better maintained).
 
 Topics that are within the scope of this book include: the meaning of (un)safety, unsafe primitives provided by the language and standard library, techniques for creating safe abstractions with those unsafe primitives, subtyping and variance, exception-safety (panic/unwind-safety), working with uninitialized memory, type punning, concurrency, interoperating with other languages (FFI), optimization tricks, how constructs lower to compiler/OS/hardware primitives, how to **not** make the memory model people angry, how you're **going** to make the memory model people angry, and more.

src/subtyping.md

@@ -75,7 +75,7 @@ this stuff really works, and how we can mess it up.
 
 The core problem is that this rule, naively applied, will lead to *meowing Dogs*. That is,
 we can convince someone that a Dog is actually a Cat. This completely destroys the fabric
-of our static type system, making it worse than useless (and leading to Undefined Behaviour).
+of our static type system, making it worse than useless (and leading to Undefined Behavior).
 
 Here's a simple example of this happening when we apply subtyping in a completely naive
 "find and replace" way.