Fix: typos (#351)

* Fix: typos Fix: typos Signed-off-by: omahs <[email protected]> * Fix: typos Fix: typos Signed-off-by: omahs <[email protected]> * Fix: typos Fix: typos Signed-off-by: omahs <[email protected]> * Fix: typos Fix: typos Signed-off-by: omahs <[email protected]> * Fix: typos Fix: typos Signed-off-by: omahs <[email protected]> Signed-off-by: omahs <[email protected]>
cosmos · Jan 13, 2023 · 3ed2246 · 3ed2246
1 parent 0067fc0
commit 3ed2246
Show file tree

Hide file tree

Showing 5 changed files with 10 additions and 10 deletions.
diff --git a/docs/architecture/adr-001-handler-implementation.md b/docs/architecture/adr-001-handler-implementation.md
@@ -164,7 +164,7 @@ A production implementation of this `Reader` would hold references to both the p
 store at the current height where the handler executes, but we omit the actual implementation as
 the store interfaces are yet to be defined, as is the general IBC top-level module machinery.
 
-A mock implementation of the `ConnectionReader` trait could looks as follows:
+A mock implementation of the `ConnectionReader` trait could look as follows:
 
 ```rust
 struct MockConnectionReader {
@@ -580,7 +580,7 @@ where
 ```
 
 With this boilerplate out of way, one can write tests using a mock client, and associated mock datatypes
-in a fairly straightforward way, taking advantage of the `From` instance to lift concerete mock datatypes
+in a fairly straightforward way, taking advantage of the `From` instance to lift concrete mock datatypes
 into the `Any...` enumeration:
 
 ```rust

diff --git a/docs/architecture/adr-002-error.md b/docs/architecture/adr-002-error.md
@@ -39,7 +39,7 @@ impl Kind {
 The design above is meant to separate between two concerns:
 
   - The metadata about an error, as captured in `Kind`.
-  - The trace of how the error occured, as captured in `anomaly::Context`.
+  - The trace of how the error occurred, as captured in `anomaly::Context`.
   - The type `Error` is defined to be `anomaly::Error<Kind>`, which is a newtype wrapper to `Box<anomaly::Context<Kind>>`.
 
 There are a few issues with the original design using `anomaly`:
@@ -76,7 +76,7 @@ are not too critical in this specific case. However this would not be the
 case if we want to use the error source information to determine whether
 an error is _recoverable_ or not. For instance, let's say if we want to
 implement custom retry logic only when the error source is
-`std::io::Error`, there is not easy way to distinguished if an error
+`std::io::Error`, there is no easy way to distinguish if an error
 variant `Kind::Grpc` is caused by `std::io::Error`.
 
 ### Proposed Design

diff --git a/docs/architecture/adr-003-ics20-implementation.md b/docs/architecture/adr-003-ics20-implementation.md
@@ -46,7 +46,7 @@ pub struct Coin<Denom> {
 }
 ```
 
-The ICS20 acknowledgement type and packet data type are defined in the spec[^2] and maybe modelled as follows. Note that
+The ICS20 acknowledgement type and packet data type are defined in the spec[^2] and may be modelled as follows. Note that
 these types must be (de)serializable from/to JSON.
 
 ```rust
@@ -197,7 +197,7 @@ pub fn on_timeout_packet<Ctx>(ctx: &Ctx, data: &FungibleTokenPacketData) -> Resu
     refund_packet_token(ctx, data)
 }
 
-/// Responds to the the success or failure of a packet
+/// Responds to the success or failure of a packet
 /// acknowledgement written on the receiving chain. If the acknowledgement
 /// was a success then nothing occurs. If the acknowledgement failed, then
 /// the sender is refunded their tokens.

diff --git a/docs/architecture/adr-004-light-client-crates-extraction.md b/docs/architecture/adr-004-light-client-crates-extraction.md
@@ -178,7 +178,7 @@ pub struct UpdateClient {
 This can be solved using the `ibc_proto::google::protobuf::Any` type instead thereby deferring the actual
 encoding/decoding to the hosts themselves during handler execution.
 Thankfully, the core modules code doesn't use the `serde` derivations except in logs and errors. Host and light-client
-implementations can optionally choose to downcast to the concrete type and use it's `serde` derivations directly (if
+implementations can optionally choose to downcast to the concrete type and use its `serde` derivations directly (if
 available).
 
 #### Light client traits cannot have constructors
@@ -477,7 +477,7 @@ Accepted
 ## References
 
 * PRs for removing `Any*` enums:
-    * Remove all occurences of Any* enums from light clients
+    * Remove all occurrences of Any* enums from light clients
       ([PR #2332](https://github.com/informalsystems/ibc-rs/pull/2332))
     * Remove Any* enums ([PR #2338](https://github.com/informalsystems/ibc-rs/pull/2338))
 * Experimental PR for extracting `ibc-base` crate ([PR #2327](https://github.com/informalsystems/ibc-rs/pull/2327))

diff --git a/docs/architecture/adr-005-handlers-redesign.md b/docs/architecture/adr-005-handlers-redesign.md
@@ -8,7 +8,7 @@ Accepted
 
 ## Context
 
-The main purpose of this ADR is to split each IBC handler (e.g. `UpdateClient`, `ConnOpenTry`, etc.) into a "validation" and an "execution" phase in order to accomodate a larger class of host architectures such as Namada. We call "validation" the part of a handler that does all the checks necessary for correctness. We call "execution" the part of the handler that applies the state modifications, assuming that validation passed. This is a necessary change for architectures like Namada. For example, for each transaction in a block, Namada first runs execution followed by validation. If validation fails, the changes are reverted. The current architecture of the IBC handlers doesn't allow for that.
+The main purpose of this ADR is to split each IBC handler (e.g. `UpdateClient`, `ConnOpenTry`, etc.) into a "validation" and an "execution" phase in order to accommodate a larger class of host architectures such as Namada. We call "validation" the part of a handler that does all the checks necessary for correctness. We call "execution" the part of the handler that applies the state modifications, assuming that validation passed. This is a necessary change for architectures like Namada. For example, for each transaction in a block, Namada first runs execution followed by validation. If validation fails, the changes are reverted. The current architecture of the IBC handlers doesn't allow for that.
 
 Our current `deliver()` entrypoint can then be split into 2 entrypoints: `validate()` and `execute()`. More specifically, we replace the current `Ics26Context` and all its supertraits with 2 traits: `ValidationContext` and `ExecutionContext`. `ValidationContext` exposes and implements the `validate()` entrypoint, while the `ExecutionContext` exposes and implements the `execute()` entrypoint. Note that we will still expose `deliver()` (perhaps slightly modified) for convenience.
 
@@ -379,7 +379,7 @@ trait ValidationContext {
     /// Returns the height when the client state for the given [`ClientId`] was updated with a header for the given [`Height`]
     fn client_update_height(&self, client_id: &ClientId, height: Height) -> Result<Height, Error>;
 
-    /// Returns a counter on the number of channel ids have been created thus far.
+    /// Returns a counter on the number of channel ids that have been created thus far.
     /// The value of this counter should increase only via method
     /// `ChannelKeeper::increase_channel_counter`.
     fn channel_counter(&self) -> Result<u64, Error>;