Merge pull request #687 from phip1611/typos

ci: add spellcheck with "typos"

Author: phip1611

.github/workflows/qa.yml

@@ -0,0 +1,12 @@
+name: QA
+
+on: [ push, pull_request ]
+
+jobs:
+  spellcheck:
+    name: Spellcheck
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/checkout@v3
+      # Executes "typos ."
+      - uses: crate-ci/[email protected]

.typos.toml

@@ -0,0 +1,13 @@
+# Configuration for the typos spell checker utility (<https://github.com/crate-ci/typos>).
+
+[files]
+extend-exclude = [
+    # "uefi/src/table/boot.rs"
+]
+
+[default.extend-words]
+# FOOBAR = "FOOBAR"
+
+[default.extend-identifiers]
+# FOOBAR = "FOOBAR"
+

PUBLISHING.md

@@ -15,7 +15,7 @@ which crates were modified and how should their version numbers be incremented.
 
 Incrementing the version number of a crate is as simple as editing
 the corresponding `Cargo.toml` file and updating the `version = ...` line,
-then commiting the change (preferrably on a new branch, so that all of the version bumps
+then committing the change (preferably on a new branch, so that all the version bumps
 can be combined in a single pull request).
 
 ### Crate dependencies

book/src/concepts/gpt.md

@@ -10,7 +10,7 @@ systems too. There are a couple big advantages of using GPT over MBR:
 
 A GPT disk contains a primary header near the beginning of the disk,
 followed by a partition entry array. The header and partition entry
-array have a secondary copy at the end of the disk for redundency. The
+array have a secondary copy at the end of the disk for redundancy. The
 partition entry arrays contain structures that describe each partition,
 including a GUID to identify the individual partition, a partition type
 GUID to indicate the purpose of the partition, and start/end block

uefi-test-runner/src/proto/debug.rs

@@ -96,7 +96,7 @@ fn test_invalidate_instruction_cache(debug_support: &mut DebugSupport) {
         debug_support
             .invalidate_instruction_cache(0, ptr, 64)
             // Should always pass, since the spec says this always returns EFI_SUCCESS
-            .expect("Error occured while invalidating instruction cache");
+            .expect("Error occurred while invalidating instruction cache");
     }
 }
 

uefi/src/data_types/mod.rs

@@ -176,7 +176,7 @@ mod tests {
         assert_eq!(X::round_up_to_alignment(7), 8);
         assert_eq!(X::round_up_to_alignment(8), 8);
 
-        // Get an intentionally mis-aligned buffer.
+        // Get an intentionally misaligned buffer.
         let mut buffer = [0u8; 16];
         let mut buffer = &mut buffer[..];
         if (buffer.as_ptr() as usize) % X::alignment() == 0 {

uefi/src/proto/console/gop.rs

@@ -631,7 +631,7 @@ impl<'gop> FrameBuffer<'gop> {
     /// # Safety
     ///
     /// This operation is unsafe because...
-    /// - It is your reponsibility to make sure that the value type makes sense
+    /// - It is your responsibility to make sure that the value type makes sense
     /// - You must honor the pixel format and stride specified by the mode info
     /// - There is no bound checking on memory accesses in release mode
     #[inline]
@@ -653,7 +653,7 @@ impl<'gop> FrameBuffer<'gop> {
     /// # Safety
     ///
     /// This operation is unsafe because...
-    /// - It is your reponsibility to make sure that the value type makes sense
+    /// - It is your responsibility to make sure that the value type makes sense
     /// - You must honor the pixel format and stride specified by the mode info
     /// - There is no bound checking on memory accesses in release mode
     #[inline]

uefi/src/proto/console/pointer/mod.rs

@@ -27,7 +27,7 @@ impl<'boot> Pointer<'boot> {
         (self.reset)(self, extended_verification).into()
     }
 
-    /// Retrieves the pointer device's current state, if a state change occured
+    /// Retrieves the pointer device's current state, if a state change occurred
     /// since the last time this function was called.
     ///
     /// Use `wait_for_input_event()` with the `BootServices::wait_for_event()`

uefi/src/proto/debug/context.rs

@@ -1,7 +1,7 @@
 // note from the spec:
 // When the context record field is larger than the register being stored in it, the upper bits of the
 // context record field are unused and ignored
-/// Universal EFI_SYSTEM_CONTEXT defintion
+/// Universal EFI_SYSTEM_CONTEXT definition
 /// This is passed to debug callbacks
 #[repr(C)]
 pub union SystemContext {

uefi/src/proto/device_path/mod.rs

@@ -1,7 +1,7 @@
 //! Device Path protocol
 //!
 //! A UEFI device path is a very flexible structure for encoding a
-//! programatic path such as a hard drive or console.
+//! programmatic path such as a hard drive or console.
 //!
 //! A device path is made up of a packed list of variable-length nodes of
 //! various types. The entire device path is terminated with an