Run codespell on CI (#136)

* Run codespell on CI

* Fix typos

.github/codespell/codespell.ini

@@ -0,0 +1,3 @@
+[codespell]
+skip = ./Code/target
+ignore-words = .github/codespell/words.txt

.github/codespell/words.txt

@@ -0,0 +1,5 @@
+crate
+shs
+ser
+numer
+manuel

.github/workflows/codespell.yml

@@ -0,0 +1,22 @@
+name: Codespell
+on:
+  pull_request:
+  push:
+    branches: main
+
+# Cancel previous runs of this workflow when a new commit is added to the PR, branch or tag
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  codespell:
+    name: Check spelling
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: codespell-project/actions-codespell@v2
+        with:
+          skip: './Code/target'
+          ignore_words_file: .github/codespell/words.txt
+

Code/driver/src/mux.rs

@@ -200,7 +200,7 @@ where
     }
 
     /// After a step change, see if there is an input to be
-    /// sent implictly to the round state machine.
+    /// sent implicitly to the round state machine.
     pub fn multiplex_step_change(
         &self,
         pending_step: Step,

Code/test/tests/driver_extra.rs

@@ -30,7 +30,7 @@ use malachite_test::utils::*;
 // - L36 with previoustly received polkaValue and proposal, and entering prevote (due to received proposal)
 //      `driver_steps_polka_value_then_proposal()`
 //
-// - L34 with previously received polkaAny and entering prevote (due to received poposal)
+// - L34 with previously received polkaAny and entering prevote (due to received proposal)
 //      `driver_steps_polka_any_then_proposal_other()`
 
 struct TestStep {
@@ -788,7 +788,7 @@ fn driver_steps_polka_value_then_proposal() {
     run_steps(&mut driver, steps);
 }
 
-// Arrive at L34 with previously received polkaAny and entering prevote (due to received poposal)
+// Arrive at L34 with previously received polkaAny and entering prevote (due to received proposal)
 //
 // Ev:             NewRound(0)           <polkaAny(v)>          Proposal(v')         + replay <polkaAny>
 // State: NewRound ------------> Propose -------------> Propose -----------> Prevote -------------------------> Prevote

Docs/architecture/adr-001-architecture.md

@@ -396,7 +396,7 @@ pub fn apply(self, data: &Info<Ctx>, input: Input<Ctx>) -> Transition<Ctx> {
 The events passed to the Round state machine are very close to the preconditions for the transition functions in the BFT paper, i.e., the `upon` clauses.
 In addition:
 - The `StartRound` events specify if the SM runs in the proposer mode or not. In the former case, the driver also passes a valid value to the round SM.
-- There are two `Poposal` events, for valid and invalid values respectively. Therefore, the `valid(v)` check is not performed in the round SM but by the Driver
+- There are two `Proposal` events, for valid and invalid values respectively. Therefore, the `valid(v)` check is not performed in the round SM but by the Driver
 
 ```rust
 pub enum Input<Ctx>

Specs/English/README.md

@@ -197,7 +197,7 @@ interaction with other modules.
 ### Round state-machine
 
 The state machine represents the operation of consensus at a single `Height(h)` and `Round(r)`.
-The diagram below offers a visual representation of the state machine. It shows the input events, using green for simple inputs (e.g. timeouts, porposal)
+The diagram below offers a visual representation of the state machine. It shows the input events, using green for simple inputs (e.g. timeouts, proposal)
 and red for the complex events (e.g. `ProposalAndPolkaCurrent` is sent to the state machine when a valid proposal and a polka of prevotes have been received).
 The actions are shown in italics (blue) and the output messages are shown in blue.
 

Specs/Quint/TendermintDSL.qnt

@@ -27,8 +27,8 @@ run ListDeliverSomeProposal (active) = {
     active.length().reps(i => deliverSomeProposal(active[i]))
 }
 
-run ProcessDeliverAllVotes(voteType, recepient, fromList, valset, h, r, value) =
-    fromList.length().reps(i => deliverVote(recepient, mkVote(voteType, fromList[i], h, r, value)))
+run ProcessDeliverAllVotes(voteType, recipient, fromList, valset, h, r, value) =
+    fromList.length().reps(i => deliverVote(recipient, mkVote(voteType, fromList[i], h, r, value)))
 
 run ListDeliverAllVotes(voteType, fromList, toList, valset, h, r, value) =
     toList.length().reps(i => ProcessDeliverAllVotes(voteType, toList[i], fromList, valset, h, r, value))

Specs/Quint/driver.qnt

@@ -446,7 +446,7 @@ module driver {
             // this might be cheating as we look into the "es"
             (state, PendingDInput(input_height_round._1))
             // I DID IT. TODO: In the "starkBFT Spec" Google doc, it is written that pending events
-            // should be executed before new messages, which would requir to push this
+            // should be executed before new messages, which would require to push this
             // branch up.
 
         else if (state.incomingProposals != Set())

Specs/Quint/voteBookkeeper.qnt

@@ -341,7 +341,7 @@ module voteBookkeeper {
     var weightedVote: WeightedVote
     // The state of the Bookkeeper.
     var bookkeeper: Bookkeeper
-    // The output outputing from applying a weighted vote to the bookkeeper.
+    // The output outputting from applying a weighted vote to the bookkeeper.
     var lastEmitted: VoteKeeperOutput
 
     // ************************************************************************