Merge pull request #211 from striezel-stash/fix-typos

Fix some typos in documentation

doc/macros/BitArr_type.md

@@ -14,7 +14,7 @@ request. As this macro is only usable in type position, it is named with
 
 You must provide a bit-count; you may optionally provide a storage type, or a
 bit-ordering *and* a storage type, as subsequent arguments. When elided, the
-type parameters are set to the crate defaut type parameters of `Lsb0` and
+type parameters are set to the crate default type parameters of `Lsb0` and
 `usize`.
 
 ```rust

doc/mem/BitElement.md

@@ -1,7 +1,7 @@
 # Unified Element Constructor
 
 This type is a hack around the fact that `Cell` and `AtomicUN` all have
-`const fn new(val: Inner) -> Self;` constructors, but the numberic fundamentals
+`const fn new(val: Inner) -> Self;` constructors, but the numeric fundamentals
 do not. As such, the standard library does not provide a unified construction
 syntax to turn an integer fundamental into the final type.
 

doc/ptr/eq.md

@@ -15,7 +15,7 @@ defines pointer equality only between pointers with the same underlying
 integer types *will not* compare equal, though this function will compile and
 accept them.
 
-This cannot compare encoded span poiters. `*const BitSlice` can be used in the
+This cannot compare encoded span pointers. `*const BitSlice` can be used in the
 standard-library `ptr::eq`, and does not need an override.
 
 ## Examples

doc/serdes.md

@@ -3,7 +3,7 @@
 `bitvec` structures are able to de/serialize their contents using `serde`.
 Because `bitvec` is itself designed to be a transport buffer and have
 memory-efficient storage properties, the implementations are somewhat strange
-and not necessarily suitable for transport across heterogenous hosts.
+and not necessarily suitable for transport across heterogeneous hosts.
 
 `bitvec` always serializes its underlying memory storage as a sequence of raw
 memory. It also includes the necessary metadata to prevent deserialization into
@@ -62,7 +62,7 @@ the word width into the serialization stream. This will prevent roundtripping a
 the types in the source code line up.
 
 This behavior was not present in version 0, and users were able to write
-programs that incorrectly handled de/serialization when used on heterogenous
+programs that incorrectly handled de/serialization when used on heterogeneous
 systems.
 
 In addition, remember that `bitvec` serializes its data buffer *directly* as

doc/slice/bitop_assign.md

@@ -21,7 +21,7 @@ same storage type.
 
 In the `0.` development series, Boolean arithmetic was implemented against all
 `I: Iterator<Item = bool>`. This allowed code such as `bits |= [false, true];`,
-but forbad acceleration in the most common use case (combining two bit-slices)
+but forbade acceleration in the most common use case (combining two bit-slices)
 because `BitSlice` is not such an iterator.
 
 Usage surveys indicate that it is better for the arithmetic operators to operate