Group typo fixes #2 (#5561)

Co-authored-by: Arr00 <13561405+arr00@users.noreply.github.com>
Co-authored-by: ernestognw <ernestognw@gmail.com>

Author: 3 people

CHANGELOG.md

@@ -7,6 +7,7 @@
 #### Custom error changes
 
 - Replace `GovernorAlreadyOverridenVote` with `GovernorAlreadyOverriddenVote`.
+- Replace `AccessControlNonRevokable` with `AccessControlNonRevocable`.
 
 ## 5.2.0 (2025-01-08)
 

contracts/interfaces/draft-IERC4337.sol

@@ -21,7 +21,7 @@ pragma solidity ^0.8.20;
  * - `paymasterData` (`bytes`): Data for paymaster (only if paymaster exists)
  * - `signature` (`bytes`): Data passed into the account to verify authorization
  *
- * When passed to on-chain contacts, the following packed version is used.
+ * When passed to on-chain contracts, the following packed version is used.
  * - `sender` (`address`)
  * - `nonce` (`uint256`)
  * - `initCode` (`bytes`): concatenation of factory address and factoryData (or empty)
@@ -164,13 +164,13 @@ interface IEntryPoint is IEntryPointNonces, IEntryPointStake {
 
     /**
      * @dev Executes a batch of user operations.
-     * @param beneficiary Address to which gas is refunded up completing the execution.
+     * @param beneficiary Address to which gas is refunded upon completing the execution.
      */
     function handleOps(PackedUserOperation[] calldata ops, address payable beneficiary) external;
 
     /**
      * @dev Executes a batch of aggregated user operations per aggregator.
-     * @param beneficiary Address to which gas is refunded up completing the execution.
+     * @param beneficiary Address to which gas is refunded upon completing the execution.
      */
     function handleAggregatedOps(
         UserOpsPerAggregator[] calldata opsPerAggregator,

contracts/interfaces/draft-IERC7579.sol

@@ -15,15 +15,15 @@ uint256 constant MODULE_TYPE_HOOK = 4;
 interface IERC7579Module {
     /**
      * @dev This function is called by the smart account during installation of the module
-     * @param data arbitrary data that may be required on the module during `onInstall` initialization
+     * @param data arbitrary data that may be passed to the module during `onInstall` initialization
      *
      * MUST revert on error (e.g. if module is already enabled)
      */
     function onInstall(bytes calldata data) external;
 
     /**
      * @dev This function is called by the smart account during uninstallation of the module
-     * @param data arbitrary data that may be required on the module during `onUninstall` de-initialization
+     * @param data arbitrary data that may be passed to the module during `onUninstall` de-initialization
      *
      * MUST revert on error
      */
@@ -186,7 +186,7 @@ interface IERC7579ModuleConfig {
      * @dev Installs a Module of a certain type on the smart account
      * @param moduleTypeId the module type ID according to the ERC-7579 spec
      * @param module the module address
-     * @param initData arbitrary data that may be required on the module during `onInstall`
+     * @param initData arbitrary data that may be passed to the module during `onInstall`
      * initialization.
      *
      * MUST implement authorization control
@@ -200,8 +200,8 @@ interface IERC7579ModuleConfig {
      * @dev Uninstalls a Module of a certain type on the smart account
      * @param moduleTypeId the module type ID according the ERC-7579 spec
      * @param module the module address
-     * @param deInitData arbitrary data that may be required on the module during `onInstall`
-     * initialization.
+     * @param deInitData arbitrary data that may be passed to the module during `onUninstall`
+     * deinitialization.
      *
      * MUST implement authorization control
      * MUST call `onUninstall` on the module with the `deInitData` parameter if provided
@@ -214,7 +214,7 @@ interface IERC7579ModuleConfig {
      * @dev Returns whether a module is installed on the smart account
      * @param moduleTypeId the module type ID according the ERC-7579 spec
      * @param module the module address
-     * @param additionalContext arbitrary data that may be required to determine if the module is installed
+     * @param additionalContext arbitrary data that may be passed to determine if the module is installed
      *
      * MUST return true if the module is installed and false otherwise
      */

contracts/mocks/docs/access-control/AccessControlModified.sol

@@ -5,10 +5,10 @@ pragma solidity ^0.8.20;
 import {AccessControl} from "../../../access/AccessControl.sol";
 
 contract AccessControlModified is AccessControl {
-    error AccessControlNonRevokable();
+    error AccessControlNonRevocable();
 
     // Override the revokeRole function
     function revokeRole(bytes32, address) public pure override {
-        revert AccessControlNonRevokable();
+        revert AccessControlNonRevocable();
     }
 }

contracts/mocks/token/ERC20ForceApproveMock.sol

@@ -4,7 +4,7 @@ pragma solidity ^0.8.20;
 
 import {ERC20} from "../../token/ERC20/ERC20.sol";
 
-// contract that replicate USDT (0xdac17f958d2ee523a2206206994597c13d831ec7) approval behavior
+// contract that replicates USDT (0xdac17f958d2ee523a2206206994597c13d831ec7) approval behavior
 abstract contract ERC20ForceApproveMock is ERC20 {
     function approve(address spender, uint256 amount) public virtual override returns (bool) {
         require(amount == 0 || allowance(msg.sender, spender) == 0, "USDT approval failure");

contracts/token/ERC20/ERC20.sol

@@ -39,8 +39,7 @@ abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
     /**
      * @dev Sets the values for {name} and {symbol}.
      *
-     * All two of these values are immutable: they can only be set once during
-     * construction.
+     * Both values are immutable: they can only be set once during construction.
      */
     constructor(string memory name_, string memory symbol_) {
         _name = name_;

contracts/token/ERC20/README.adoc

@@ -7,11 +7,11 @@ This set of interfaces, contracts, and utilities are all related to the https://
 
 TIP: For an overview of ERC-20 tokens and a walk through on how to create a token contract read our xref:ROOT:erc20.adoc[ERC-20 guide].
 
-There are a few core contracts that implement the behavior specified in the ERC:
+There are a few core contracts that implement the behavior specified in the ERC-20 standard:
 
 * {IERC20}: the interface all ERC-20 implementations should conform to.
-* {IERC20Metadata}: the extended ERC-20 interface including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> functions.
-* {ERC20}: the implementation of the ERC-20 interface, including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> optional standard extension to the base interface.
+* {IERC20Metadata}: the extended ERC-20 interface including the <<ERC20-name--,`name`>>, <<ERC20-symbol--,`symbol`>> and <<ERC20-decimals--,`decimals`>> functions.
+* {ERC20}: the implementation of the ERC-20 interface, including the <<ERC20-name--,`name`>>, <<ERC20-symbol--,`symbol`>> and <<ERC20-decimals--,`decimals`>> optional extensions to the standard interface.
 
 Additionally there are multiple custom extensions, including:
 
@@ -30,9 +30,9 @@ Finally, there are some utilities to interact with ERC-20 contracts in various w
 
 * {SafeERC20}: a wrapper around the interface that eliminates the need to handle boolean return values.
 
-Other utilities that support ERC-20 assets can be found in codebase:
+Other utilities that support ERC-20 assets can be found in the codebase:
 
-* ERC-20 tokens can be timelocked (held tokens for a beneficiary until a specified time) or vested (released following a given schedule) using a {VestingWallet}.
+* ERC-20 tokens can be timelocked (held for a beneficiary until a specified time) or vested (released following a given schedule) using a {VestingWallet}.
 
 NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC-20 (such as <<ERC20-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer.
 

contracts/utils/TransientSlot.sol

@@ -32,7 +32,7 @@ pragma solidity ^0.8.24;
  */
 library TransientSlot {
     /**
-     * @dev UDVT that represents a slot holding a address.
+     * @dev UDVT that represents a slot holding an address.
      */
     type AddressSlot is bytes32;
 

docs/modules/ROOT/pages/utilities.adoc

@@ -12,7 +12,7 @@ At a high level, signatures are a set of cryptographic algorithms that allow for
 
 ==== Ethereum Signatures (secp256k1)
 
-xref:api:utils.adoc#ECDSA[`ECDSA`] provides functions for recovering and managing Ethereum account ECDSA signatures. These are often generated via https://web3js.readthedocs.io/en/v1.7.3/web3-eth.html#sign[`web3.eth.sign`], and are a 65 byte array (of type `bytes` in Solidity) arranged the following way: `[[v (1)], [r (32)], [s (32)]]`.
+xref:api:utils.adoc#ECDSA[`ECDSA`] provides functions for recovering and managing Ethereum account ECDSA signatures. These are often generated via https://web3js.readthedocs.io/en/v1.7.3/web3-eth.html#sign[`web3.eth.sign`], and form a 65-byte array (of type `bytes` in Solidity) arranged the following way: `[[v (1)], [r (32)], [s (32)]]`.
 
 The data signer can be recovered with xref:api:utils.adoc#ECDSA-recover-bytes32-bytes-[`ECDSA.recover`], and its address compared to verify the signature. Most wallets will hash the data to sign and add the prefix `\x19Ethereum Signed Message:\n`, so when attempting to recover the signer of an Ethereum signed message hash, you'll want to use xref:api:utils.adoc#MessageHashUtils-toEthSignedMessageHash-bytes32-[`toEthSignedMessageHash`].
 
@@ -197,7 +197,7 @@ The `Enumerable*` structures are similar to mappings in that they store and remo
 
 Building an on-chain Merkle Tree allows developers to keep track of the history of roots in a decentralized manner. For these cases, the xref:api:utils.adoc#MerkleTree[`MerkleTree`] includes a predefined structure with functions to manipulate the tree (e.g. pushing values or resetting the tree).
 
-The Merkle Tree does not keep track of the roots purposely, so that developers can choose their tracking mechanism. Setting up and using a Merkle Tree in Solidity is as simple as follows:
+The Merkle Tree does not keep track of the roots intentionally, so that developers can choose their tracking mechanism. Setting up and using a Merkle Tree in Solidity is as simple as follows:
 
 NOTE: Functions are exposed without access control for demonstration purposes
 
@@ -243,7 +243,7 @@ function _hashFn(bytes32 a, bytes32 b) internal view returns(bytes32) {
 
 === Using a Heap
 
-A https://en.wikipedia.org/wiki/Binary_heap[binary heap] is a data structure that always store the most important element at its peak and it can be used as a priority queue.
+A https://en.wikipedia.org/wiki/Binary_heap[binary heap] is a data structure that always stores the most important element at its peak and it can be used as a priority queue.
 
 To define what is most important in a heap, these frequently take comparator functions that tell the binary heap whether a value has more relevance than another.
 
@@ -358,7 +358,7 @@ This is especially useful for building URL-safe tokenURIs for both xref:api:toke
 
 Here is an example to send JSON Metadata through a Base64 Data URI using an ERC-721:
 
-[source, solidity]
+[source,solidity]
 ----
 include::api:example$utilities/Base64NFT.sol[]
 ----

hardhat/ignore-unreachable-warnings.js

@@ -3,7 +3,7 @@
 // with hardhat-ignore-warnings we are not able to selectively ignore them without potentially ignoring relevant
 // warnings that we don't want to miss.
 // Thus, we need to handle these warnings separately. We force Hardhat to compile them in a separate compilation job and
-// then ignore the warnings about unreachable code that come from that compilation job.
+// then ignore the warnings about unreachable code coming from that compilation job.
 
 const { task } = require('hardhat/config');
 const {