ci: Run typos tool on docs to catch typos

Seems to have no false positives on the documentation, so seems nice to
have in CI. It does have some false positives on `grease*/`, so we can't
check that in CI. I ran it manually and fixed some typos.

https://github.com/crate-ci/typos

Author: langston-barrett

.github/workflows/lint.yml

@@ -24,6 +24,13 @@ jobs:
 
           ./hlint-3.8/hlint grease{,-aarch32,-ppc,-x86}/src grease-cli/{main,src,tests}
 
+      - name: Spell check docs
+        # We pin a specific version because updates can come with additional
+        # typo fixes. These could break CI unexpectedly if we just pinned @v1.
+        uses: crate-ci/typos@v1.32.0
+        with:
+          files: doc/
+
       - name: Find stale TODOs
         shell: bash
         env:

doc/dev.md

@@ -158,13 +158,13 @@ organized into different subdirectories:
    test cases has the file extension `*.bc`.
 
 3. `arm`: AArch32 machine-code CFGs (via `macaw-aarch32-syntax`). Each of these
-   test cases has the file exension `*.armv7l.cbl`.
+   test cases has the file extension `*.armv7l.cbl`.
 
 4. `ppc32`: PPC32 machine-code CFGs (via `macaw-ppc-syntax`). Each of these test
-   cases has the file exension `*.ppc32.cbl`.
+   cases has the file extension `*.ppc32.cbl`.
 
 5. `x86`: x86-64 machine-code CFGs (via `macaw-x86-syntax`). Each of these test
-   cases has the file exension `*.x64.cbl`.
+   cases has the file extension `*.x64.cbl`.
 
 ### Lua API
 

doc/memory-model.md

@@ -50,7 +50,7 @@ Mutable global variables are tricky:
   trigger the bug isn't actually feasible at any of the callsites to the
   function under analysis.
 - On the other hand, if GREASE doesn't initialize global variables at all, any
-  loads from them (that aren't preceeded by writes made by the function under
+  loads from them (that aren't preceded by writes made by the function under
   analysis or its callees) will fail. As mutable global variables are pervasive,
   this would lead to a significant lack of coverage.
 

doc/shape-dsl.md

@@ -32,7 +32,7 @@ Where:
 - `uninit N` represents `N` uninitialized bytes of memory
 - `init N` represents `N` bytes of memory initialized to symbolic bytes
 - `exactly byte+` represents a concrete sequence of bytes
-- `memptr` represents a pointer to a futher allocation
+- `memptr` represents a pointer to a further allocation
 
 At certain verbosity levels, GREASE may output these preconditions in its logs.
 It does so using a concrete syntax described below.

doc/shared-libraries.md

@@ -37,7 +37,7 @@ relocation type associated with the PLT stub, e.g.,
 grease: Attempted to read from an unsupported relocation type (R_X86_64_GLOB_DAT) at address 0x3ff0.
 This may be due to a PLT stub that grease did not detect.
 If so, try passing --plt-stub <ADDR>:<NAME>, where
-<ADDR> and <NAME> can be obtained by diassembling the
+<ADDR> and <NAME> can be obtained by disassembling the
 relevant PLT section of the binary
 (.plt, .plt.got, .plt.sec, etc.).
 ```

doc/undefined-behavior.md

@@ -14,7 +14,7 @@ In the C abstract machine, such behavior is clearly undefined.
 However, if the program is compiled in a straightforward way into machine code, the distinction between different stack variables is lost.
 The resulting code simply performs several innocuous-looking writes to the stack.
 Similarly, adding two signed integers in C might result in an undefined signed overflow.
-At the machine code level, there is no distinction betwen signed and unsigned integers, and arithmetic operations generally have a well-defined semantics for all inputs (e.g., based on a two's complement representation).
+At the machine code level, there is no distinction between signed and unsigned integers, and arithmetic operations generally have a well-defined semantics for all inputs (e.g., based on a two's complement representation).
 
 GREASE aims to be pragmatic in what it calls a bug.
 It uses a C-like memory model, and reports behaviors of binaries that would likely constitute undefined behavior in C.

grease-cli/tests/Makefile

@@ -58,7 +58,7 @@ STRIPPED_STATIC_ARM_EXES   = $(addsuffix /test.armv7l.elf,$(STRIPPED_STATIC_DIRS
 STRIPPED_STATIC_X64_EXES   = $(addsuffix /test.x64.elf,$(STRIPPED_STATIC_DIRS))
 STRIPPED_STATIC_PPC32_EXES = $(addsuffix /test.ppc32.elf,$(STRIPPED_STATIC_DIRS))
 
-# Thest test cases depend on libc, but rely on static linking to ensure that
+# These test cases depend on libc, but rely on static linking to ensure that
 # all of the relevant code from libc is inlined into the binary.
 #
 # For instance, the sanity/pass/syscall test case crucially relies

grease-cli/tests/llvm/double-free.llvm.cbl

@@ -11,5 +11,5 @@
 ;; next_line_must_fail()
     (funcall h p)
     (return ())))
-; TODO: This error mesage is not great... it doesn't mention double-frees
+; TODO: This error message is not great... it doesn't mention double-frees
 ;; check "The free function"

grease/src/Grease/LLVM/Overrides.hs

@@ -347,7 +347,7 @@ registerLLVMOverrides la builtinOvs paths bak halloc llvmCtx decls = do
       Just ov -> registerOv ov
 
   -- Note the order again: user overrides (registered later) will take
-  -- precendence over built-in overrides (registered here).
+  -- precedence over built-in overrides (registered here).
   let ovs = Foldable.toList builtinOvs
   builtinOvs' <- CLLVM.register_llvm_overrides_ llvmCtx ovs allDecls
   builtinOvs'' <-

grease/src/Grease/Macaw.hs

@@ -505,7 +505,7 @@ assertRelocSupported arch (Mem.LLVMPointer _base offset) relocs =
                  ") at address " <> tshow addr <> "."
                , "This may be due to a PLT stub that grease did not detect."
                , "If so, try passing --plt-stub <ADDR>:<NAME>, where"
-               , "<ADDR> and <NAME> can be obtained by diassembling the"
+               , "<ADDR> and <NAME> can be obtained by disassembling the"
                , "relevant PLT section of the binary"
                , "(.plt, .plt.got, .plt.sec, etc.)."
                ]