Merge pull request #2330 from samdotola/main

fix typos

Author: chipshort

MIGRATING.md

@@ -148,8 +148,8 @@ major releases of `cosmwasm`. Note that you can also view the
   +CosmosMsg::Any(AnyMsg { type_url, value })
   ```
 
-- Replace all direct construction of `StdError` with use of the corresponding
-  constructor:
+- Replace all direct construction of `StdError` with the use of the
+  corresponding constructor:
 
   ```diff
   -StdError::GenericErr { msg }
@@ -259,7 +259,7 @@ major releases of `cosmwasm`. Note that you can also view the
 
   The payload data will then be available in the new field `Reply.payload` in
   the `reply` entry point. This functionality is an optional addition introduced
-  in 2.0. To keep the CosmWasm 1.x behaviour, just set payload to
+  in 2.0. To keep the CosmWasm 1.x behavior, just set payload to
   `Binary::default()`.
 
 - In test code, replace calls to `mock_info` with `message_info`. This takes a
@@ -393,7 +393,7 @@ major releases of `cosmwasm`. Note that you can also view the
   # ...
   ```
 
-- There are changes to how we generate schemas, resulting in less boilerplace
+- There are changes to how we generate schemas, resulting in less boilerplate
   maintenance for smart contract devs. Old contracts will continue working for a
   while, but it's highly recommended to migrate now.
 
@@ -570,9 +570,9 @@ arbitrary ones.
   annotations. See the [0.13 -> 0.14 entry](#013---014) where `#[entry_point]`
   was introduced.
 
-- If your chain provides a custom queries, add the custom query type as a
-  generic argument to `cosmwasm_std::Deps`, `DepsMut`, `OwnedDeps` and
-  `QuerierWrapper`. Otherwise it defaults to `Empty`. E.g.
+- If your chain provides a custom query, add the custom query type as a generic
+  argument to `cosmwasm_std::Deps`, `DepsMut`, `OwnedDeps` and `QuerierWrapper`.
+  Otherwise, it defaults to `Empty`. E.g.
 
   ```diff
    #[entry_point]
@@ -1313,30 +1313,30 @@ arbitrary ones.
   which a compact binary representation is desired. For JSON state this does not
   save much data (e.g. the bech32 address
   cosmos1pfq05em6sfkls66ut4m2257p7qwlk448h8mysz takes 45 bytes as direct ASCII
-  and 28 bytes when its canonical representation is base64 encoded). For fixed
-  length database keys `CanonicalAddr` remains handy though.
+  and 28 bytes when its canonical representation is base64 encoded). For
+  fixed-length database keys `CanonicalAddr` remains handy though.
 
 - Replace `StakingMsg::Withdraw` with `DistributionMsg::SetWithdrawAddress` and
   `DistributionMsg::WithdrawDelegatorReward`. `StakingMsg::Withdraw` was a
   shorthand for the two distribution messages. However, it was unintuitive
-  because it did not set the address for one withdraw only but for all following
-  withdrawls. Since withdrawls are [triggered by different
+  because it did not set the address for one withdrawal only but for all
+  following withdrawals. Since withdrawals are [triggered by different
   events][distribution docs] such as validators changing their commission rate,
   an address that was set for a one-time withdrawal would be used for future
-  withdrawls not considered by the contract author.
+  withdrawals not considered by the contract author.
 
-  If the contract never set a withdraw address other than the contract itself
+  If the contract never set a withdrawal address other than the contract itself
   (`env.contract.address`), you can simply replace `StakingMsg::Withdraw` with
   `DistributionMsg::WithdrawDelegatorReward`. It is then never changed from the
-  default. Otherwise you need to carefully track what the current withdraw
-  address is. A one-time change can be implemented by emitted 3 messages:
+  default. Otherwise, you need to carefully track what the current withdrawal
+  address is. A one-time change can be implemented by emitting 3 messages:
 
   1. `SetWithdrawAddress { address: recipient }` to temporarily change the
      recipient
   2. `WithdrawDelegatorReward { validator }` to do a manual withdrawal from the
      given validator
   3. `SetWithdrawAddress { address: env.contract.address.into() }` to change it
-     back for all future withdrawls
+     back for all future withdrawals
 
   [distribution docs]: https://docs.cosmos.network/v0.42/modules/distribution/
 
@@ -1534,7 +1534,7 @@ arbitrary ones.
   }
   ```
 
-  Once you got familiar with the concept, you can create different error types
+  Once you get familiar with the concept, you can create different error types
   for each of the contract's functions.
 
   You can also try a different error library than
@@ -1786,8 +1786,8 @@ Contract code and uni tests:
 - `cosmwasm_storage::get_with_prefix`, `cosmwasm_storage::set_with_prefix`,
   `cosmwasm_storage::RepLog::commit`, `cosmwasm_std::ReadonlyStorage::get`,
   `cosmwasm_std::ReadonlyStorage::range`, `cosmwasm_std::Storage::set` and
-  `cosmwasm_std::Storage::remove` now return the value directly that was wrapped
-  in a result before.
+  `cosmwasm_std::Storage::remove` now returns the value directly that was
+  wrapped in a result before.
 - Error creator functions are now in type itself, e.g.
   `StdError::invalid_base64` instead of `invalid_base64`. The free functions are
   deprecated and will be removed before 1.0.
@@ -1876,7 +1876,7 @@ Contract Code:
 
 - Complete overhaul of `cosmwasm::Error` into `cosmwasm_std::StdError`:
   - Auto generated snafu error constructor structs like `NotFound`/`ParseErr`/…
-    have been privatized in favour of error generation helpers like
+    have been privatized in favor of error generation helpers like
     `not_found`/`parse_err`/…
   - All error generator functions now return errors instead of results, such
     that e.g. `return unauthorized();` becomes `return Err(unauthorized());`
@@ -1911,7 +1911,7 @@ Both:
 - `dependencies` was renamed to `mock_dependencies`. `mock_dependencies` and
   `mock_instance` take a 2nd argument to set the contract balance (visible for
   the querier). If you need to set more balances, use `mock_XX_with_balances`.
-  The follow code block explains:
+  The following code block explains:
 
   ```rust
   // before: balance as last arg in mock_env
@@ -1933,7 +1933,7 @@ Integration Tests:
   - Before:
     `match err { ContractResult::Err(msg) => assert_eq!(msg, "Unauthorized"), ... }`
   - After: `match err { Err(StdError::Unauthorized{ .. }) => {}, ... }`
-- Remove all imports / use of `ContractResult`
+- Remove all imports/use of `ContractResult`
 - You must specify `CosmosMsg::Native` type when calling
   `cosmwasm_vm::testing::{handle, init}`. You will want to
   `use cosmwasm_std::{HandleResult, InitResult}` or

README.md

@@ -129,8 +129,8 @@ repo.
 
 We also recommend you review our [documentation site](https://book.cosmwasm.com)
 which contains a few tutorials to guide you in building your first contracts.
-You can find past recordings of hackathon / conference workshops and
-presentations on our [YouTube channel](https://www.youtube.com/@CosmWasm), or
+You can find past recordings of hackathon/conference workshops and presentations
+on our [YouTube channel](https://www.youtube.com/@CosmWasm), or
 [join our Discord server](https://chat.cosmwasm.com) to ask for help.
 
 ## Minimum Supported Rust Version (MSRV)
@@ -190,7 +190,7 @@ extern "C" fn ibc_packet_ack(env_ptr: u32, msg_ptr: u32) -> u32;
 extern "C" fn ibc_packet_timeout(env_ptr: u32, msg_ptr: u32) -> u32;
 ```
 
-`allocate`/`deallocate` allow the host to manage data within the Wasm VM. If
+`allocate` and `deallocate` allow the host to manage data within the Wasm VM. If
 you're using Rust, you can implement them by simply
 [re-exporting them from cosmwasm::exports](https://github.com/CosmWasm/cosmwasm/blob/v0.6.3/contracts/hackatom/src/lib.rs#L5).
 `instantiate`, `execute` and `query` must be defined by your contract.
@@ -298,7 +298,7 @@ pub struct Region {
 ## Implementing the Smart Contract
 
 If you followed the [instructions above](#Creating-a-smart-contract), you should
-have a runable smart contract. You may notice that all of the Wasm exports are
+have a runnable smart contract. You may notice that all of the Wasm exports are
 taken care of by `lib.rs`, which you shouldn't need to modify. What you need to
 do is simply look in `contract.rs` and implement `instantiate` and `execute`
 functions, defining your custom `InstantiateMsg` and `ExecuteMsg` structs for

SEMANTICS.md

@@ -16,9 +16,9 @@ semantics apply to any other _mutating_ action - `instantiate`, `migrate`,
 
 Before looking at CosmWasm, we should look at the (somewhat under-documented)
 semantics enforced by the blockchain framework we integrate with - the
-[Cosmos SDK](https://v1.cosmos.network/sdk). It is based upon the
+[Cosmos SDK](https://v1.cosmos.network/sdk). It is based on the
 [Tendermint BFT](https://tendermint.com/core/) Consensus Engine. Let us first
-look how they process transactions before they arrive in CosmWasm (and after
+look at how they process transactions before they arrive in CosmWasm (and after
 they leave).
 
 First, the Tendermint engine will seek 2/3+ consensus on a list of transactions
@@ -38,7 +38,7 @@ The Cosmos SDK `BaseApp` handles each transaction in an isolated context. It
 first verifies all signatures and deducts the gas fees. It sets the "Gas Meter"
 to limit the execution to the amount of gas paid for by the fees. Then it makes
 an isolated context to run the transaction. This allows the code to read the
-current state of the chain (after the last transaction finished), but it only
+current state of the chain (after the last transaction is finished), but it only
 writes to a cache, which may be committed or rolled back on error.
 
 A transaction may consist of multiple messages and each one is executed in turn
@@ -116,7 +116,7 @@ to be provable and can return some essential state (although in general client
 apps rely on Events more). This result is more commonly used to pass results
 between contracts or modules in the sdk. Note that the `ResultHash` includes
 only the `Code` (non-zero meaning error) and `Result` (data) from the
-transaction. Events and log are available via queries, but there are no
+transaction. Events and logs are available via queries, but there are no
 light-client proofs possible.
 
 If the contract sets `data`, this will be returned in the `result` field.
@@ -137,7 +137,7 @@ The final result looks like this to the client:
 
 ### Dispatching Messages
 
-Now let's move onto the `messages` field. Some contracts are fine only talking
+Now let's move on to the `messages` field. Some contracts are fine only talking
 with themselves, such as a cw20 contract just adjusting its balances on
 transfers. But many want to move tokens (native or cw20) or call into other
 contracts for more complex actions. This is where messages come in. We return
@@ -169,8 +169,8 @@ executed in `x/wasm` _with the permissions of the contract_ (meaning
 `info.sender` will be the contract not the original caller). If they return
 success, they will emit a new event with the custom attributes, the `data` field
 will be ignored, and any messages they return will also be processed. If they
-return an error, the parent call will return an error, thus rolling back state
-of the whole transaction.
+return an error, the parent call will return an error, thus rolling back the
+state of the whole transaction.
 
 Note that the messages are executed
 [_depth-first_](https://en.wikipedia.org/wiki/Depth-first_search). This means if
@@ -192,12 +192,12 @@ graph TD;
 ```
 
 This may be hard to understand at first. "Why can't I just call another
-contract?", you may ask. However, we do this to prevent one of most widespread
-and hardest to detect security holes in Ethereum contracts - reentrancy. We do
-this by following the actor model, which doesn't nest function calls, but
-returns messages that will be executed later. This means all state that is
-carried over between one call and the next happens in storage and not in memory.
-For more information on this design, I recommend you read
+contract?", you may ask. However, we do this to prevent one of the most
+widespread and hardest to detect security holes in Ethereum contracts -
+reentrancy. We do this by following the actor model, which doesn't nest function
+calls, but returns messages that will be executed later. This means all state
+that is carried over between one call and the next happens in storage and not in
+memory. For more information on this design, I recommend you read
 [our docs on the Actor Model](https://book.cosmwasm.com/actor-model.html).
 
 ### Submessages
@@ -244,15 +244,15 @@ pub enum ReplyOn {
 }
 ```
 
-What are the semantics of a submessage execution. First, we create a
+What are the semantics of a submessage execution? First, we create a
 sub-transaction context around the state, allowing it to read the latest state
 written by the caller, but write to yet-another cache. If `gas_limit` is set, it
 is sandboxed to how much gas it can use until it aborts with `OutOfGasError`.
 This error is caught and returned to the caller like any other error returned
 from contract execution (unless it burned the entire gas limit of the
 transaction). What is more interesting is what happens on completion.
 
-If it return success, the temporary state is committed (into the caller's
+If it returns success, the temporary state is committed (into the caller's
 cache), and the `Response` is processed as normal (an event is added to the
 current EventManager, messages and submessages are executed). Once the
 `Response` is fully processed, this may then be intercepted by the calling
@@ -264,12 +264,12 @@ intercepted by the calling contract (for `ReplyOn::Always` and
 transaction_
 
 Note, that error doesn't abort the whole transaction _if and only if_ the
-`reply` is called - so in case of `ReplyOn::Always` and `ReplyOn::Error`. If the
-submessage is called with `ReplyOn::Success` (or `ReplyOn::Never`, which makes
-it effectively a normal message), the error in subsequent call would result in
-failing whole transaction and not commit the changes for it. The rule here is as
-follows: if for any reason you want your message handling to succeed on
-submessage failure, you always have to reply on failure.
+`reply` is called - so in the case of `ReplyOn::Always` and `ReplyOn::Error`. If
+the submessage is called with `ReplyOn::Success` (or `ReplyOn::Never`, which
+makes it effectively a normal message), the error in subsequent call would
+result in failing the whole transaction and not committing the changes for it.
+The rule here is as follows: if for any reason you want your message handling to
+succeed on submessage failure, you always have to reply on failure.
 
 Obviously - on the successful processing of sub-message, if the reply is not
 called (in particular `ReplyOn::Error`), the whole transaction is assumed to