Spellcheck

CHANGELOG.md

@@ -12,7 +12,7 @@ This document is written according to the [Keep a Changelog][kac] style.
    1. [0.20.2](#0202)
    1. [0.20.0](#0200)
       1. [Pointer Overhaul](#pointer-overhaul)
-      1. [Aliasing Typesystem](#aliasing-typesystem)
+      1. [Aliasing Type System](#aliasing-type-system)
       1. [`&bool` to `BitRef`](#bool-to-bitref)
 1. [0.19](#019)
    1. [0.19.4](#0194)
@@ -71,7 +71,7 @@ This document is written according to the [Keep a Changelog][kac] style.
 
 Provides named types as the result of `Iter::by_ref` and `Iter::by_val`. Renames
 `BitTail` to `BitEnd`, which is publicly visible. Reduced to a patch change by
-provididng a type alias.
+providing a type alias.
 
 ### 0.22.2 <!-- omit in toc -->
 
@@ -143,7 +143,7 @@ This has been a valuable lesson for future work, especially as 1.0 approaches.
 #### Fixed <!-- omit in toc -->
 
 GitHub user [@ordian] fixed incorrect `len()` exclusion from `BitVec::insert` in
-[Pull Requst #104].
+[Pull Request #104].
 
 ## 0.20
 
@@ -184,7 +184,7 @@ notices.
   into the same scope.
 
   This adapter permits loops that satisfy this condition to remove the
-  performance cost of alias-safed memory accesses where the user has ensured
+  performance cost of alias-safe memory accesses where the user has ensured
   that no alias conditions will exist.
 
   As an example, the following loop may safely use `.remove_alias()`:
@@ -222,7 +222,7 @@ notices.
 
 The pointer infrastructure in the crate has been entirely rewritten. This does
 not affect the encoding structure used in `*BitSlice` pointers; it is primarily
-a typesystem arrangement.
+a type-system arrangement.
 
 The previous `BitPtr` type has bene renamed to `BitSpan`. `BitSpan` retains all
 responsibility for managing the encoding of `*BitSlice` pointers, and is
@@ -248,7 +248,7 @@ components: the exact types used when marking bit-slices as aliased, and the
 removal of `&bool` references in favor of the same proxy type that had been
 standing in for `&mut bool`.
 
-#### Aliasing Typesystem
+#### Aliasing Type System
 
 The types used when a `&mut BitSlice` aliases its underlying memory are now
 specialized wrappers rather than bare `Atomic` or `Cell<>` types. These new
@@ -437,7 +437,7 @@ them internally.
 #### Added <!-- omit in toc -->
 
 - The CI test harness now covers targets beyond `x86_64-unknown-linux-gnu`,
-  thanks to GitHub user [@Alexhuszagh]. `bitvec` guarantees support for all
+  thanks to GitHub user [@AlexHuszagh]. `bitvec` guarantees support for all
   targets listed in the CI matrix through at least the next major release. If
   your target is not in this list, please file an issue for inclusion.
 
@@ -453,7 +453,7 @@ past, such as in GitHub [issue #32], and is still (as of writing) not able to be
 array type that is large enough to hold the number of bits that the user wants.
 
 The `bitarr!` macro constructs either values of `BitArray<O, V>` with the same
-syntax as the other three macros, or constructs `BitArary<O, V>` typenames
+syntax as the other three macros, or constructs `BitArray<O, V>` type names
 suitable for a number of bits in a given order/store array. Invoked as
 `bitarr!(for BITS, in ORDER, STORE)`, it produces a typename that can be used to
 correctly type locations that cannot use inference from a value assigned  into
@@ -554,7 +554,7 @@ management error in the `0.17` series, and is demonstrated to exist back to
 
 #### Fixed <!-- omit in toc -->
 
-GitHub users [@Alexhuszagh] and [@obeah] noted in [Issue #43] that the sequence
+GitHub users [@AlexHuszagh] and [@obeah] noted in [Issue #43] that the sequence
 storage constructors used by the `bits!` macro yielded incorrect behavior. The
 error was a copy-paste error in the production of byte reördering functions used
 by the macro.
@@ -604,15 +604,15 @@ The `AsBits::as_{mut_,}bitslice` deprecation aliases have been removed.
 
 - `BitField` trait now has `{load,store}_{le,be}` methods for explicitly
   choosing *element* order when performing storage. The `load`/`store` methods
-  default to the target’s byte endiannes as a convenience. These may be
+  default to the target’s byte endianness as a convenience. These may be
   deprecated in the future, if the explicit choice is strongly preferred.
 
   See the module and trait documentation for more detail.
 
 - GitHub user [@mystor] provided a `bits!` macro in [Pull Request #34] which
   enables compile-time construction of `&'static BitSlice<O, T>` regions. This
   macro is currently limited to working with the literal `BitOrder`
-  implementator names `Local`, `Lsb0`, and `Msb0`. This is a restriction in the
+  implementor names `Local`, `Lsb0`, and `Msb0`. This is a restriction in the
   Rust language (identifiers are not yet associated with types during macro
   expansion), and `bitvec` does not promise to expand support to other names or
   types in the future.
@@ -665,7 +665,7 @@ it expected to be present.
   respectively; `as_bitslice` and `as_mut_bitslice` are marked deprecated and
   will be removed in `0.17`.
 - The `BitField` trait allows `BitSlice<BigEndian, _>` and
-  `BitSlice<LittleEndian, _>` to provide behavior analagous to bitfields in C
+  `BitSlice<LittleEndian, _>` to provide behavior analogous to bitfields in C
   and C++ `struct` definitions. This trait provides `load` and `store` methods
   on `BitSlice`s with those two `Cursor`s which allow for parallel access to the
   underlying memory. This trait is currently not able to be implemented by
@@ -861,7 +861,7 @@ dependency on `alloc`, and the allocating types. The `std` feature alone now
 
 - **SEE THE RENAME BELOW.** The `Bits` and `BitsMut` traits provide reference
   conversion from many Rust fundamental types to `BitSlice` regions. `Bits` is
-  analagous to `AsRef`, and `BitsMut` to `AsMut`. These traits are implemented
+  analogous to `AsRef`, and `BitsMut` to `AsMut`. These traits are implemented
   on the `BitStore` fundamentals, slices of them, and arrays up to 32.
 
 - `BitSlice::get_unchecked` and `BitSlice::set_unchecked` perform read and write
@@ -1222,7 +1222,7 @@ Initial implementation and release.
 - `BitVec` type with basic `Vec` idioms and parallel trait implementations
 - `bitvec!` generator macro
 
-[@Alexhuszagh]: https://github.com/Alexhuszagh
+[@AlexHuszagh]: https://github.com/AlexHuszagh
 [@Fotosmile]: https://github.com/Fotosmile
 [@GeorgeGkas]: https://github.com/GeorgeGkas
 [@HamishWMC]: https://github.com/HamishWMC

README.md

@@ -8,8 +8,6 @@
 [![Documentation][docs_img]][docs]
 [![License][license_img]][license_file]
 
-[![Continuous Integration][travis_img]][travis]
-[![Code Coverage][codecov_img]][codecov]
 [![Crate Downloads][downloads_img]][crate]
 [![Crate Size][loc_img]][loc]
 
@@ -46,7 +44,7 @@ registers are powers of bytes in size. Data that does not evenly fill a byte, or
 a power of a byte, creates inconveniences for the machine and for the
 programmer.
 
-`bitvec` removes the human-facing inconveniences by modelling memory as if it
+`bitvec` removes the human-facing inconveniences by modeling memory as if it
 were addressed as individual bits, and registers as if they supported any width.
 
 If you need to work with data that does not evenly fill one of the fundamental
@@ -398,7 +396,7 @@ then `bitvec` will fall back to non-atomic, non-threadsafe, behavior for that
 integer.
 
 You may disable this feature to unconditionally use [`Cell`]-based memory access
-to aliased locations, thereby disabling multithreading support in
+to aliased locations, thereby disabling multi-threading support in
 [`&/mut BitSlice`] and ensuring that memory access always uses ordinary
 load/store instructions.
 

book/bit-ordering.md

@@ -106,7 +106,7 @@ bit  ║ 76543210│76543210│76543210│76543210│76543210│76543210│76543
 
 On big-endian machines, the most-significant *byte* of a register type is stored
 at the lowest memory address, and each byte higher is one step less numerically
-signifcant than the last.
+significant than the last.
 
 ```text
 byte ║ 00000000│11111111│22222222│33333333│44444444│55555555│66666666│77777777

book/data-structures/bitslice.md

@@ -35,7 +35,7 @@ to address only ⅛<sup>th</sup> of the indices that `[bool]` can.
 ## Getting a `BitSlice`
 
 `BitSlice` is strictly a borrowed region. It can neither be created nor
-destroyed; rather, views to it are aquired from a memory buffer that some other
+destroyed; rather, views to it are acquired from a memory buffer that some other
 binding owns.
 
 The [`BitStore` chapter] covers this in more detail, but only sequences of the

book/dedication.md

@@ -1,6 +1,6 @@
 # Dedication
 
-I begain working on `bitvec` shortly before I was told that my father had been
+I began working on `bitvec` shortly before I was told that my father had been
 diagnosed with cancer for the third time. Developing the library gave me
 something into which to sink my attention and keep my mind from dwelling on his
 rapidly-progressing illness. I wrote the core pointer representation that

book/memory-model.md

@@ -126,7 +126,7 @@ As soon as you attempt to read the bit-wise value of `poison`, your program is
 undefined[^3].
 
 So if `bitvec` wants to be threadsafe, which it does, and it wants to insist on
-its ability to safely alias the same memory location from mulitple handles,
+its ability to safely alias the same memory location from multiple handles,
 which is non-negotiable, there’s only one avenue left to take.
 
 ### Atomic Powered Microscopes
@@ -393,7 +393,7 @@ has a more robust arbitrary-bit-tracking capability, but similarly limits its
 interface to external code.
 
 Barring any errors in the `bitvec` implementation, the `bitvec` memory model is
-fully sound in its behavior with regard to single-observer unsynchrony.
+fully sound in its behavior with regard to single-observer race freedom.
 Synchronization is only added in order to correctly interface with `rustc` and
 LLVM without causing either of them to introduce undefined behavior due to a
 lack of information.
@@ -430,8 +430,8 @@ simultaneous production of `::Mem` and `::Alias` aliasing references.
       much luck producing a benchmark that firmly demonstrates that unneeded
       atomic access is a strict performance cost.
 
-[^5]: In multithreading environments. Disabling atomics also disables `bitvec`’s
-      support for multithreading, so the penalty for aliasing is reduced to an
+[^5]: In multi-threaded environments. Disabling atomics also disables `bitvec`’s
+      support for multi-threaded, so the penalty for aliasing is reduced to an
       inability to remove redundant reads.
 
 [bv_ord]: https://github.com/myrrlyn/bitvec/blob/HEAD/src/order.rs

book/pointer-encoding.md

@@ -16,7 +16,7 @@ through these functions and the compiler will accept them as valid.
 
 These requirements traditionally make it difficult to encode non-address
 information into a bare reference, since the compiler has a very firm
-expectation that a reference to a type is immediately dereferencable to a value
+expectation that a reference to a type is immediately dereferencëable to a value
 of that type, but if your type happens to be zero-sized, then it can never exist
 in memory, no loads or stores to it can ever be produced, and the compiler no
 longer concerns itself with the actual bit-pattern value of references to it.
@@ -78,7 +78,7 @@ struct BitSpan<T> {
 
   uintptr_t ptr_head : __builtin_ctzll(alignof(T));
   uintptr_t ptr_addr : sizeof(uintptr_t) * CHAR_BITS;
-                     - __builtin_tczll(alignof(T));
+                     - __builtin_ctzll(alignof(T));
 
   size_t len_head : 3;
   size_t len_bits : sizeof(size_t) * 8 - 3;

examples/tour.rs

@@ -15,11 +15,11 @@ use bitvec::prelude::{
 	bits,
 	//  element-traversal trait (you shouldn’t explicitly need this)
 	BitOrder,
-	//  slice type, analagous to `[u1]`
+	//  slice type, analogous to `[u1]`
 	BitSlice,
 	//  trait unifying the primitives (you shouldn’t explicitly need this)
 	BitStore,
-	//  vector type, analagous to `Vec<u1>`
+	//  vector type, analogous to `Vec<u1>`
 	BitVec,
 	//  directionality type markers
 	Lsb0,

src/access.rs

@@ -7,7 +7,7 @@ unaliased access events.
 
 The [`BitAccess`] trait provides capabilities to access bits in memory elements
 through shared references, and its implementations are responsible for
-coördinating synchronization and contention as needed.
+coördinating synchronization and contention as needed.
 
 The [`BitSafe`] trait abstracts over wrappers to the [`Cell`] and [atomic] types
 that forbid writing through their references, even when other references to the
@@ -349,22 +349,22 @@ mod tests {
 		let (c, _): (&mut BitSlice<Msb0, BitSafeU8>, _) = c.split_at_mut(16);
 
 		//  Get a write-capable shared reference to the base address,
-		let l_redge: &<BitSafeU8 as BitSafe>::Rad =
+		let l_r_edge: &<BitSafeU8 as BitSafe>::Rad =
 			l.domain_mut().region().unwrap().2.unwrap().0;
 		//  and a write-incapable shared reference to the same base address.
-		let c_ledge: &BitSafeU8 = c.domain().region().unwrap().0.unwrap().1;
+		let c_l_edge: &BitSafeU8 = c.domain().region().unwrap().0.unwrap().1;
 
 		//  The split location means that the two subdomains share a location.
 		assert_eq!(
-			l_redge as *const _ as *const u8,
-			c_ledge as *const _ as *const u8,
+			l_r_edge as *const _ as *const u8,
+			c_l_edge as *const _ as *const u8,
 		);
 
 		//  The center reference can only read,
-		assert_eq!(c_ledge.load(), 0);
+		assert_eq!(c_l_edge.load(), 0);
 		//  while the left reference can write,
-		l_redge.set_bits(BitMask::new(6));
+		l_r_edge.set_bits(BitMask::new(6));
 		//  and be observed by the center.
-		assert_eq!(c_ledge.load(), 6);
+		assert_eq!(c_l_edge.load(), 6);
 	}
 }

src/array.rs

@@ -114,7 +114,7 @@ This type is useful for marking that some value is always to be used as a
 ///     Self {
 ///       header: 0,
 ///       // creates a value object.
-///       // the type paramaters must be repeated.
+///       // the type parameters must be repeated.
 ///       fields: bitarr![Msb0, u8; 0; 20],
 ///     }
 ///   }

src/boxed.rs

@@ -11,13 +11,13 @@ code.
 relationship to the [`BitSlice`] and [`BitVec`] types. Most of the interesting
 work to be done on a bit-sequence is implemented in `BitSlice`, to which
 `BitBox` dereferences, and the box container itself only exists to maintain
-wonership and provide some specializations that cannot safely be done on
+ownership and provide some specializations that cannot safely be done on
 `BitSlice` alone.
 
 There is almost never a reason to use this type, as it is a mixture of
 [`BitArray`]’s fixed width and [`BitVec`]’s heap allocation. You should only use
 it when you have a bit-sequence whose width is either unknowable at compile-time
-or inexpressable in `BitArray`, and are constructing the sequence in a `BitVec`
+or inexpressible in `BitArray`, and are constructing the sequence in a `BitVec`
 before freezing it.
 
 [`BitArray`]: crate::array::BitArray
@@ -64,7 +64,7 @@ pub use iter::IntoIter;
 /** A frozen heap-allocated buffer of individual bits.
 
 This is essentially a [`BitVec`] that has frozen its allocation, and given up
-the ability to change size. It is analagous to `Box<[bool]>`. You should prefer
+the ability to change size. It is analogous to `Box<[bool]>`. You should prefer
 [`BitArray`] over `BitBox` where possible, and may freely box it if you need the
 indirection.
 
@@ -331,7 +331,7 @@ where
 		slice length as the buffer capacity. However, this is *not* a behavior
 		guaranteed by the distribution, and so the pipeline above must remain in
 		place in the event that this behavior ever changes. It should compile
-		away to nothing, as it is almost entirely typesystem manipulation.
+		away to nothing, as it is almost entirely type system manipulation.
 		*/
 		unsafe {
 			bitspan.set_address(raw.as_mut_ptr());

src/boxed/iter.rs

@@ -101,7 +101,7 @@ where
 
 	#[doc(hidden)]
 	#[inline(always)]
-	#[cfg(not(tarpalin_include))]
+	#[cfg(not(tarpaulin_include))]
 	#[deprecated = "Use `as_bitslice` to view the underlying slice"]
 	pub fn as_slice(&self) -> &BitSlice<O, T> {
 		self.as_bitslice()

src/boxed/traits.rs

@@ -204,7 +204,7 @@ where
 	}
 }
 
-#[cfg(not(tarpauln_include))]
+#[cfg(not(tarpaulin_include))]
 impl<O, T> AsRef<BitSlice<O, T>> for BitBox<O, T>
 where
 	O: BitOrder,
@@ -216,7 +216,7 @@ where
 	}
 }
 
-#[cfg(not(tarpauln_include))]
+#[cfg(not(tarpaulin_include))]
 impl<O, T> AsMut<BitSlice<O, T>> for BitBox<O, T>
 where
 	O: BitOrder,

src/domain.rs

@@ -86,7 +86,7 @@ macro_rules! bit_domain {
 		/// # Aliasing Awareness
 		///
 		/// This enum does not grant access to memory outside the scope of the
-		/// original [`BitSlice`] handle, and so does not need to modfiy any
+		/// original [`BitSlice`] handle, and so does not need to modify any
 		/// aliasing conditions.
 		///
 		/// [`BitSlice`]: crate::slice::BitSlice

src/field.rs

@@ -250,7 +250,7 @@ trait to operate on a de/serialization buffer, where the exact bit pattern in
 memory is important to your work and/or you need to be aware of the processor
 byte endianness, you must not use these methods.
 
-Instead, use [`load_le`], [`load_be`], [`store_le`], or[`store_be`] directly.
+Instead, use [`load_le`], [`load_be`], [`store_le`], or [`store_be`] directly.
 
 The un-suffixed methods choose their implementation based on the target
 processor byte endianness; the suffixed methods have a consistent and fixed
@@ -1043,6 +1043,24 @@ where T: BitStore
 			},
 		}
 	}
+
+	fn load<M>(&self) -> M
+	where M: BitMemory {
+		#[cfg(target_endian = "little")]
+		return self.load_le::<M>();
+
+		#[cfg(target_endian = "big")]
+		return self.load_be::<M>();
+	}
+
+	fn store<M>(&mut self, value: M)
+	where M: BitMemory {
+		#[cfg(target_endian = "little")]
+		self.store_le(value);
+
+		#[cfg(target_endian = "big")]
+		self.store_be(value);
+	}
 }
 
 impl<T> BitField for BitSlice<Msb0, T>