Add typos to CI (#1158)

Hi all!

This CL fixes #1093:
* Avoids including current false-positives in the checking of typos
* Excludes localization-related files, as `typos` works with
  English words
* Fixes existing typos caught in the repo

Tested this in CI with a typo and it showed up in the list of actions!

---------

Co-authored-by: Martin Geisler <martin@geisler.net>

.github/typos.toml

@@ -0,0 +1,16 @@
+[default.extend-identifiers]
+# False positives.
+mis = "mis"
+MIS = "MIS"
+inout = "inout"
+BARs = "BARs"
+
+[type.po]
+# Localized content should not be checked for typos. English
+# in these files should be validated manually.
+extend-glob = ["*.po"]
+check-file = false
+
+[files]
+# Typos in third party packages should be fixed upstream.
+extend-exclude = ["third_party/*"]

.github/workflows/build.yml

@@ -24,6 +24,11 @@ jobs:
       - name: Check formatting
         uses: dprint/check@v2.2
 
+      - name: Check for typos
+        uses: crate-ci/typos@v1.16.9
+        with:
+          config: ./.github/typos.toml
+
   cargo:
     strategy:
       matrix:

po/uk.po

@@ -3669,7 +3669,7 @@ msgstr ""
 
 #: src/exercises/day-1/for-loops.md:102
 msgid ""
-"An implicit array copy would have occured.  Since `i32` is a copy type, then "
+"An implicit array copy would have occurred.  Since `i32` is a copy type, then "
 "`[i32; 3]` is also a copy type."
 msgstr ""
 
@@ -13791,7 +13791,7 @@ msgstr ""
 msgid ""
 "If it were running in a VM, this can lead to cache coherency issues. The "
 "problem is that the VM is accessing memory directly with the cache disabled, "
-"while the host has cachable aliases to the same memory. Even if the host "
+"while the host has cacheable aliases to the same memory. Even if the host "
 "doesn't explicitly access the memory, speculative accesses can lead to cache "
 "fills, and then changes from one or the other will get lost when the cache "
 "is cleaned or the VM enables the cache. (Cache is keyed by physical address, "
@@ -14778,7 +14778,7 @@ msgstr ""
 msgid ""
 "If it were running in a VM, this can lead to cache coherency issues. The "
 "problem is that the VM is accessing memory directly with the cache disabled, "
-"while the host has cachable aliases to the same memory. Even if the host "
+"while the host has cacheable aliases to the same memory. Even if the host "
 "doesn't explicitly access the memory, speculative accesses can lead to cache "
 "fills, and then changes from one or the other will get lost. Again this is "
 "alright in this particular case (running directly on the hardware with no "

src/async/pitfalls/cancellation.md

@@ -79,7 +79,7 @@ async fn main() -> std::io::Result<()> {
 
     * Whenever the `tick()` branch finishes first, `next()` and its `buf` are dropped.
 
-    * `LinesReader` can be made cancellation-safe by makeing `buf` part of the struct:
+    * `LinesReader` can be made cancellation-safe by making `buf` part of the struct:
         ```rust,compile_fail
         struct LinesReader {
             stream: DuplexStream,

src/bare-metal/aps/entry-point.md

@@ -21,7 +21,7 @@ Before we can start running Rust code, we need to do some initialisation.
     which sets `+strict-align` to prevent the compiler generating unaligned accesses, so it should
     be fine in this case, but this is not necessarily the case in general.
   * If it were running in a VM, this can lead to cache coherency issues. The problem is that the VM
-    is accessing memory directly with the cache disabled, while the host has cachable aliases to the
+    is accessing memory directly with the cache disabled, while the host has cacheable aliases to the
     same memory. Even if the host doesn't explicitly access the memory, speculative accesses can
     lead to cache fills, and then changes from one or the other will get lost when the cache is
     cleaned or the VM enables the cache. (Cache is keyed by physical address, not VA or IPA.)

src/bare-metal/aps/other-projects.md

@@ -20,7 +20,7 @@
     which sets `+strict-align` to prevent the compiler generating unaligned accesses so it should be
     alright, but this is not necessarily the case in general.
   * If it were running in a VM, this can lead to cache coherency issues. The problem is that the VM
-    is accessing memory directly with the cache disabled, while the host has cachable aliases to the
+    is accessing memory directly with the cache disabled, while the host has cacheable aliases to the
     same memory. Even if the host doesn't explicitly access the memory, speculative accesses can
     lead to cache fills, and then changes from one or the other will get lost. Again this is alright
     in this particular case (running directly on the hardware with no hypervisor), but isn't a good

src/bare-metal/aps/uart.md

@@ -19,6 +19,6 @@ The QEMU 'virt' machine has a [PL011][1] UART, so let's write a driver for that.
 * This is a common pattern for writing safe wrappers of unsafe code: moving the burden of proof for
   soundness from a large number of places to a smaller number of places.
 
-</detais>
+</details>
 
 [1]: https://developer.arm.com/documentation/ddi0183/g

src/exercises/day-1/for-loops.md

@@ -86,7 +86,7 @@ Without the `&`...
 * The loop would have been one that consumes the array.  This is a
   change [introduced in the 2021
   Edition](https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterator-for-arrays.html).
-* An implicit array copy would have occured.  Since `i32` is a copy type, then
+* An implicit array copy would have occurred.  Since `i32` is a copy type, then
   `[i32; 3]` is also a copy type.
 
 </details>