[autofix.ci] apply automated fixes

Author: autofix-ci[bot]

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 the use of the corresponding
-  constructor:
+- Replace all direct construction of `StdError` with the use of the
+  corresponding constructor:
 
   ```diff
   -StdError::GenericErr { msg }
@@ -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 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.
+- 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,13 +1313,14 @@ 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 withdrawal only but for all following
-  withdrawals. Since withdrawals 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
   withdrawals not considered by the contract author.
@@ -1785,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 returns 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.

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)

SEMANTICS.md

@@ -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 the 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 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
+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
@@ -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 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.
+`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