Remove extra umlauts on a and e in english words

CHANGELOG.md

@@ -203,7 +203,7 @@ from crates.io in the future.
 - Fixed an incomplete change of default type parameters from `LocalBits` to
   `Lsb0`.
 - Introduced the `BitStore::Alias` system for coöperative mutation.
-- Reärranged the view conversion traits, creating `BitView` alongside `AsBits`
+- Rearranged the view conversion traits, creating `BitView` alongside `AsBits`
   and `AsBitsMut`.
 - Greatly improved cross-compile testing with a CI suite by [@AlexHuszagh].
 - Removed numeric arithmetic, per [Issue #17] (by me) and [Issue #50] by GitHub
@@ -229,7 +229,7 @@ from crates.io in the future.
 - Fixed [Issue #40] with [Pull Request #41], both provided by GitHub user
   [@ImmemorConsultrixContrarie].
 - Fixed [Issue #43], reported by GitHub users [@AlexHuszagh] and [@obeah].
-- Fixed an improper deällocation, per [Issue #55] reported by GitHub user
+- Fixed an improper deallocation, per [Issue #55] reported by GitHub user
   [@kulp].
 
 ### 0.16
@@ -241,14 +241,14 @@ from crates.io in the future.
 - Changed default type parameters to `<Local, Word>`.
 - Created the `index` module, reducing runtime assertions.
 - Fixed [Issue #33], reported by GitHub sure [@jonas-schievink], which addressed
-  incorrect reällocation in `BitVec::reserve`.
+  incorrect reallocation in `BitVec::reserve`.
 - Updated `radium` dependency to `0.3`, fixing [Issue #36] reported by GitHub
   user [@lynaghk].
 
 ### 0.15
 
 - Raised MSRV to `1.36`.
-- Reärranged the feature set to use the now-available `extern crate alloc;`.
+- Rearranged the feature set to use the now-available `extern crate alloc;`.
 - Conditionally remove `Send` from `BitSlice`.
 - Improve the `bitvec!` repetition constructor, as reported in [Issue #28] by
   GitHub user [@caelunshun].

README.md

@@ -122,7 +122,7 @@ Once Cargo knows about it, bring its prelude into scope:
 use bitvec::prelude::*;
 ```
 
-You can read the [prelude reëxports][prelude] to see exactly which symbols are
+You can read the [prelude reexports][prelude] to see exactly which symbols are
 being imported. The prelude brings in many symbols, and while name collisions
 are not likely, you may wish to instead import the prelude *module* rather than
 its contents:

SECURITY.md

@@ -30,7 +30,7 @@ It *should* be unaffected by other classes of vulnerability.
 
 Any incorrect behavior found when operating on a `bitvec` data structure that
 has not been modified or tampered with by the user is a fault in `bitvec`, and
-should be reported. However, `bitvec` does not, and cannot, proäctively defend
+should be reported. However, `bitvec` does not, and cannot, proactively defend
 against adversarial modification of the objects it gives to users. Incorrect
 modification of objects later passed in to `bitvec` *will* crash your system,
 and this is *not* a bug in `bitvec`.

book/data-structures/bitslice.md

@@ -129,7 +129,7 @@ To summarize the macro rules:
 
 - If the first macro argument is `mut`, then the macro produces `&mut BitSlice`,
   otherwise it produces `&BitSlice`. You do not need to bind the name as `mut`
-  unless you want to reässign it to a different slice.
+  unless you want to reassign it to a different slice.
 - You may then optionally provide the storage and ordering type parameters,
   followed by a semicolon. If you choose to add type parameters:
   - You *must* provide the bit-ordering parameter.

book/memory-model.md

@@ -75,7 +75,7 @@ there yet.
 
 Since an `&mut BitSlice<T, _>` handle cannot produce an `&mut T` reference to
 perform writes to memory, it must instead either use a `*mut T` bare pointer,
-which has absolutely no checks or optimizations whatsoëver, or use an
+which has absolutely no checks or optimizations whatsoever, or use an
 `&UnsafeCell<T>` shared reference, which has all the usual guarantees present on
 all[^1] reference types.
 
@@ -180,7 +180,7 @@ of thread-safety. For builds that do permit atomics, the marker enforces that
 all reads and writes use atomic instructions.
 
 The `::Alias` marker is applied, at compile time, by operations that split
-`&mut BitSlice` references into multiple coëxisting subslices. This is a good
+`&mut BitSlice` references into multiple coexisting subslices. This is a good
 first step to reducing unnecessary synchrony, but not good enough. Consider the
 following:
 

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 dereferenceäble to a value
+expectation that a reference to a type is immediately dereferenceable 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.

doc/boxed/iter.md

@@ -6,6 +6,6 @@ In the standard library, this iterator is defined under `alloc::vec`, not
 to its boxed value.
 
 It is moved here for simplicity: both `BitBox` and `BitVec` iterate over a
-dynamic bit-slice by value, and must deällocate the region when dropped. As
+dynamic bit-slice by value, and must deallocate the region when dropped. As
 `BitBox` has a smaller value than `BitVec`, it is used as the owning handle for
 the bit-slice being iterated.

doc/domain/BitDomain.md

@@ -12,7 +12,7 @@ prior call to [`.split_at_mut()`] for as much of the bit-slice as possible.
 ## Why Not `Option`?
 
 The `Enclave` variant always contains as its single field the exact bit-slice
-that created the `Enclave`. As such, this type is easily replaceäble with an
+that created the `Enclave`. As such, this type is easily replaceable with an
 `Option` of the `Region` variant, which when `None` is understood to be the
 original.
 

doc/macros/encode_bits.md

@@ -21,7 +21,7 @@ to the 32-bit or 64-bit encoding, depending on the target.
 ## Zero Extension
 
 The next two arms handle extending the list of bit-expressions with 64 `0,`s.
-The first arm captures initial reëntry and appends the zero-comma tokens, then
+The first arm captures initial reentry and appends the zero-comma tokens, then
 recurses to enter the chunking group. The second arm traps when recursion has
 chunked all user-provided tokens, and only the literal `0,` tokens appended by
 the first arm remain.

doc/ptr/BitPtr.md

@@ -4,7 +4,7 @@ This structure defines a pointer to exactly one bit in a memory element. It is a
 structure, rather than an encoding of a `*Bit` raw pointer, because it contains
 more information than can be packed into such a pointer. Furthermore, it can
 uphold the same requirements and guarantees that the rest of the crate demands,
-whereäs a raw pointer cannot.
+whereas a raw pointer cannot.
 
 ## Original
 

doc/serdes.md

@@ -20,7 +20,7 @@ changes its behavior, but as it is run while compiling `bitvec` itself, clients
 that rename `bitvec` when bringing it into their namespace should not be
 affected.
 
-Note that because `LocalBits` is a reëxport rather than a type in its own right,
+Note that because `LocalBits` is a reexport rather than a type in its own right,
 it always serializes as the real type to which it forwards. This prevents
 accidental mismatch when transporting between machines with different
 destinations for this alias.

doc/store.md

@@ -77,7 +77,7 @@ right of observation for all bits in its region, the unsigned integers alias to
 a crate-internal wrapper over the alias-capable standard-library types. This
 wrapper forbids mutation through shared references, so two [`BitSlice`]
 references that alias a memory location, but do not overlap in bits, may not be
-coërced to interfere with each other.
+coerced to interfere with each other.
 
 [atomic]: core::sync::atomic
 [unsigned integers]: core::primitive

src/boxed.rs

@@ -118,7 +118,7 @@ where
 
 	/// Attempts to convert an ordinary boxed slice into a boxed bit-slice.
 	///
-	/// This does not perform a copy or reällocation; it only attempts to
+	/// This does not perform a copy or reallocation; it only attempts to
 	/// transform the handle. Because `Box<[T]>` can be longer than `BitBox`es,
 	/// it may fail, and will return the original handle if it does.
 	///
@@ -176,7 +176,7 @@ where
 	/// Converts the bit-box into a bit-vector.
 	///
 	/// This uses the Rust allocator API, and does not guarantee whether or not
-	/// a reällocation occurs internally.
+	/// a reallocation occurs internally.
 	///
 	/// The resulting bit-vector can be converted back into a bit-box via
 	/// [`BitBox::into_boxed_bitslice`][0].

src/boxed/api.rs

@@ -66,7 +66,7 @@ where
 	/// Consumes the bit-box, returning a raw bit-slice pointer.
 	///
 	/// Bit-slice pointers are always correctly encoded and non-null. The
-	/// referent region is dereferenceäble *as a `BitSlice` for the remainder of
+	/// referent region is dereferenceable *as a `BitSlice` for the remainder of
 	/// the program, or until it is first passed to [`::from_raw()`], whichever
 	/// comes first. Once the pointer is first passed to `::from_raw()`, all
 	/// copies of that pointer become invalid to dereference.
@@ -85,7 +85,7 @@ where
 	/// let bb = unsafe { BitBox::from_raw(ptr) };
 	/// ```
 	///
-	/// You **may not** deällocate pointers produced by this function through
+	/// You **may not** deallocate pointers produced by this function through
 	/// any other means.
 	///
 	/// [`::from_raw()`]: Self::from_raw

src/ptr/single.rs

@@ -897,7 +897,7 @@ where
 	///
 	/// ## Safety
 	///
-	/// There are no guarantees whatsoëver that offsetting the bit-pointer will
+	/// There are no guarantees whatsoever that offsetting the bit-pointer will
 	/// not overflow or go beyond the allocation that the bit-pointer selects.
 	/// It is up to the caller to ensure that the returned offset is correct in
 	/// all terms other than alignment.

src/ptr/span.rs

@@ -445,7 +445,7 @@ where
 		}
 	}
 
-	/// Reäligns a bit-span to a different base memory type.
+	/// Realigns a bit-span to a different base memory type.
 	///
 	/// ## Original
 	///

src/slice.rs

@@ -73,7 +73,7 @@ where
 	/// slice type here (such as `[u8]` or `[T]`) would require that `&/mut
 	/// BitSlice` handles have values that correctly describe the region, and
 	/// the encoding *does not* do this. As such, reference handles to
-	/// `BitSlice` must not be even implicitly dereferenceäble to real memory,
+	/// `BitSlice` must not be even implicitly dereferenceable to real memory,
 	/// and the slice must be a ZST.
 	///
 	/// References to a ZST have no restrictions about what the values can be,

src/slice/api.rs

@@ -2270,7 +2270,7 @@ where
 	/// You may not use this to cast away alias protections. Rust does not have
 	/// support for higher-kinded types, so this cannot express the relation
 	/// `Outer<T> -> Outer<U> where Outer: BitStoreContainer`, but memory safety
-	/// does require that you respect this rule. Reälign integers to integers,
+	/// does require that you respect this rule. Realign integers to integers,
 	/// `Cell`s to `Cell`s, and atomics to atomics, but do not cross these
 	/// boundaries.
 	///
@@ -2322,7 +2322,7 @@ where
 	/// You may not use this to cast away alias protections. Rust does not have
 	/// support for higher-kinded types, so this cannot express the relation
 	/// `Outer<T> -> Outer<U> where Outer: BitStoreContainer`, but memory safety
-	/// does require that you respect this rule. Reälign integers to integers,
+	/// does require that you respect this rule. Realign integers to integers,
 	/// `Cell`s to `Cell`s, and atomics to atomics, but do not cross these
 	/// boundaries.
 	///

src/vec.rs

@@ -202,7 +202,7 @@ where
 	/// Converts a regular vector in-place into a bit-vector.
 	///
 	/// The produced bit-vector spans every bit in the original vector. No
-	/// reällocation occurs; this is purely a transform of the handle.
+	/// reallocation occurs; this is purely a transform of the handle.
 	///
 	/// ## Panics
 	///
@@ -227,7 +227,7 @@ where
 	///
 	/// This fails if the source vector is too long to view as a bit-slice. On
 	/// success, the produced bit-vector spans every bit in the original vector.
-	/// No reällocation occurs; this is purely a transform of the handle.
+	/// No reallocation occurs; this is purely a transform of the handle.
 	///
 	/// ## Examples
 	///
@@ -373,7 +373,7 @@ where
 
 	/// Converts a bit-vector into a boxed bit-slice.
 	///
-	/// This may cause a reällocation to drop any excess capacity.
+	/// This may cause a reallocation to drop any excess capacity.
 	///
 	/// ## Original
 	///

src/vec/api.rs

@@ -186,7 +186,7 @@ where
 	/// Gets the allocation capacity, measured in bits.
 	///
 	/// This counts how many total bits the bit-vector can store before it must
-	/// perform a reällocation to acquire more memory.
+	/// perform a reallocation to acquire more memory.
 	///
 	/// If the capacity is not a multiple of 8, you should call
 	/// [`.force_align()`].

tests/issues.rs

@@ -56,13 +56,13 @@ fn issue_10() {
 /** Test case for [Issue #33], opened by [@jonas-schievink].
 
 This report discovered an error in the implementation of `BitVec::reserve`,
-which caused it to fail to reällocate in certain conditions.
+which caused it to fail to reallocate in certain conditions.
 
 The error was that the `reserve` method was testing the reservation amount
 passed in to `Vec::reserve` against the currently-allocated *capacity*, not the
 currently-occupied *element length*. `Vec::reserve` expects the difference to be
 against the element length, so `BitVec::reserve` was estimating too few elements
-and `Vec::reserve` did not see the request amount as requiring a reällocation.
+and `Vec::reserve` did not see the request amount as requiring a reallocation.
 
 `BitVec::reserve` now tests the reservation amount against the current element
 length, which produces the correct reservation request for `Vec::reserve`,
@@ -213,7 +213,7 @@ fn issue_65() {
 
 /** Test case for [Issue #69], opened by [@YoshikiTakashima].
 
-This report shows a dereference after deällocation. This is not *strictly* true:
+This report shows a dereference after deallocation. This is not *strictly* true:
 the destructor only used the value of the pointer, and did not issue a load or
 store instruction through it, but even that use was sufficient to trip Miri’s
 alarms.