Group typo fixes (#5466)

Co-authored-by: Bilog WEB3 <155262265+Bilogweb3@users.noreply.github.com>
Co-authored-by: Fallengirl <155266340+Fallengirl@users.noreply.github.com>
Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com>
Co-authored-by: XxAlex74xX <30472093+XxAlex74xX@users.noreply.github.com>
Co-authored-by: Arr00 <13561405+arr00@users.noreply.github.com>
Co-authored-by: PixelPilot <161360836+PixelPil0t1@users.noreply.github.com>
Co-authored-by: kilavvy <140459108+kilavvy@users.noreply.github.com>
Co-authored-by: Devkuni <155117116+detrina@users.noreply.github.com>
Co-authored-by: Danbo <140512416+dannbbb1@users.noreply.github.com>
Co-authored-by: Ann Wagner <chant_77_swirly@icloud.com>
Co-authored-by: comfsrt <155266597+comfsrt@users.noreply.github.com>
Co-authored-by: Bob <158583129+bouchmann@users.noreply.github.com>
Co-authored-by: JohnBonny <158583902+JohnBonny@users.noreply.github.com>
Co-authored-by: moonman <155266991+moooonman@users.noreply.github.com>
Co-authored-by: kazak <alright-epsilon8h@icloud.com>
Co-authored-by: Wei <ybxerlvqtx@rambler.ru>
Co-authored-by: Maxim Evtush <154841002+maximevtush@users.noreply.github.com>
Co-authored-by: Vitalyr <158586577+Vitaliyr888@users.noreply.github.com>
Co-authored-by: pendrue <158588659+pendrue@users.noreply.github.com>
Co-authored-by: Tronica <wudmytrotest404@gmail.com>
Co-authored-by: emmmm <155267286+eeemmmmmm@users.noreply.github.com>
Co-authored-by: bigbear <155267841+aso20455@users.noreply.github.com>
Co-authored-by: Tomás Andróil <tomasandroil@gmail.com>
Co-authored-by: GooseMatrix <155266802+GooseMatrix@users.noreply.github.com>
Co-authored-by: jasmy <3776356370@qq.com>
Co-authored-by: SITADRITA1 <mrlime2018@gmail.com>
Co-authored-by: Ocenka <testoviydiman1@gmail.com>

Author: 28 people

.changeset/brown-turkeys-marry.md

@@ -2,4 +2,4 @@
 'openzeppelin-solidity': minor
 ---
 
-`ER6909TokenSupply`: Add an extension of ERC6909 which tracks total supply for each token id.
+`ERC6909TokenSupply`: Add an extension of ERC6909 which tracks total supply for each token id.

.github/actions/gas-compare/action.yml

@@ -2,18 +2,18 @@ name: Compare gas costs
 description: Compare gas costs between branches
 inputs:
   token:
-    description: github token
+    description: GitHub token, required to access GitHub API
     required: true
   report:
-    description: report to read from
+    description: Path to the report to compare
     required: false
     default: gasReporterOutput.json
   out_report:
-    description: report to read
+    description: Path to save the output report
     required: false
     default: ${{ github.ref_name }}.gasreport.json
   ref_report:
-    description: report to read from
+    description: Path to the reference report for comparison
     required: false
     default: ${{ github.base_ref }}.gasreport.json
 

.github/workflows/checks.yml

@@ -43,7 +43,7 @@ jobs:
         run: npm run test:inheritance
       - name: Check pragma consistency between files
         run: npm run test:pragma
-      - name: Check proceduraly generated contracts are up-to-date
+      - name: Check procedurally generated contracts are up-to-date
         run: npm run test:generation
       - name: Compare gas costs
         uses: ./.github/actions/gas-compare

CHANGELOG.md

@@ -427,7 +427,7 @@ Instead, contracts now revert with custom errors. Systems that interact with sma
 
 ##### Relying on storage locations for retrieving data
 
-After 5.0, the storage location of some variables were changed. This is the case for `Initializable` and all the upgradeable contracts since they now use namespaced storaged locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.
+After 5.0, the storage location of some variables was changed. This is the case for `Initializable` and all the upgradeable contracts since they now use namespaced storage locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.
 
 ## 4.9.6 (2024-02-29)
 

GUIDELINES.md

@@ -6,7 +6,7 @@ Code must be thoroughly tested with quality unit tests.
 
 We defer to the [Moloch Testing Guide](https://github.com/MolochVentures/moloch/tree/master/test#readme) for specific recommendations, though not all of it is relevant here. Note the introduction:
 
-> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests are just as important (if not more so) than the code itself, and should be written with the highest standards of clarity and elegance.
+> Tests should be written, not only to verify correctness of the target code, but to be comprehensively reviewed by other programmers. Therefore, for mission critical Solidity code, the quality of the tests is just as important (if not more so) than the code itself, and should be written to the highest standards of clarity and elegance.
 
 Every addition or change to the code must come with relevant and comprehensive tests.
 

RELEASING.md

@@ -1,6 +1,6 @@
 # Releasing
 
-OpenZeppelin Contracts uses a fully automated release process that takes care of compiling, packaging, and publishing the library, all of which is carried out in a clean CI environment (GitHub Actions), implemented in the ([`release-cycle`](.github/workflows/release-cycle.yml)) workflow. This helps to reduce the potential for human error and inconsistencies, and ensures that the release process is ongoing and reliable.
+OpenZeppelin Contracts uses a fully automated release process that takes care of compiling, packaging, and publishing the library, all of which is carried out in a clean CI environment (GitHub Actions), implemented in the [`release-cycle`](.github/workflows/release-cycle.yml) workflow. This helps to reduce the potential for human error and inconsistencies, and ensures that the release process is consistent and reliable.
 
 ## Changesets
 

audits/2017-03.md

@@ -20,7 +20,7 @@ The git commit hash we evaluated is:
 
 # Disclaimer
 
-The audit makes no statements or warrantees about utility of the code, safety of the code, suitability of the business model, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bug free status. The audit documentation is for discussion purposes only.
+The audit makes no statements or warranties about utility of the code, safety of the code, suitability of the business model, regulatory regime for the business model, or any other statements about fitness of the contracts to purpose, or their bug free status. The audit documentation is for discussion purposes only.
 
 # Executive Summary
 
@@ -90,7 +90,7 @@ We are still working through the confirmation protocol in `Shareable.sol`, but w
 This bug has a number of causes that need to be addressed:
 
 1. `resetSpentToday` and `confirm` together do not limit the days on which the function can be called or (it appears) the number of times it can be called.
-1. Once a call has been confirmed and `execute`d it appears that it can be re-executed. This is not good.
+1. Once a call has been confirmed and executed it appears that it can be re-executed. This is not good.
 3. `confirmandCheck` doesn't seem to have logic about whether or not the function in question has been called.
 4. Even if it did, `revoke` would need updates and logic to deal with revocation requests after a function call had been completed.
 
@@ -109,7 +109,7 @@ It would be nice to see how many payments are pending. This would imply a bit of
 
 ## Shareable Contract
 
-We do not believe the `Shareable.sol` contract is ready for primetime. It is missing functions, and as written may be vulnerable to a reordering attack -- an attack in which a miner or other party "racing" with a smart contract participant inserts their own information into a list or mapping.
+We do not believe the `Shareable.sol` contract is ready for prime time. It is missing functions, and as written may be vulnerable to a reordering attack -- an attack in which a miner or other party "racing" with a smart contract participant inserts their own information into a list or mapping.
 
 The confirmation and revocation code needs to be looked over with a very careful eye imagining extraordinarily bad behavior by shared owners before this contract can be called safe.
 
@@ -159,7 +159,7 @@ Allows owner to set a public string of contract information. No issues.
 
 This needs some work. Doesn't check if `_required <= len(_owners)` for instance, that would be a bummer. What if _required were like `MAX - 1`?
 
-I have a general concern about the difference between `owners`, `_owners`, and `owner` in `Ownable.sol`. I recommend "Owners" be renamed. In general we do not recomment single character differences in variable names, although a preceding underscore is not uncommon in Solidity code.
+I have a general concern about the difference between `owners`, `_owners`, and `owner` in `Ownable.sol`. I recommend "Owners" be renamed. In general we do not recommend single character differences in variable names, although a preceding underscore is not uncommon in Solidity code.
 
 Line 34: "this contract only has six types of events"...actually only two.
 
@@ -224,7 +224,7 @@ Transfer() and transferFrom() use SafeMath functions, which will cause them to t
 
 ### SimpleToken
 
-Sample instantiation of StandardToken. Note that in this sample, decimals is 18 and supply only 10,000, so the supply is a small fraction of a single nominal token.
+Sample instantiation of StandardToken. Note that in this sample, decimals is 18 and supply is only 10,000, so the supply is a small fraction of a single nominal token.
 
 ### CrowdsaleToken
 

contracts/access/IAccessControl.sol

@@ -23,7 +23,7 @@ interface IAccessControl {
      * @dev Emitted when `newAdminRole` is set as ``role``'s admin role, replacing `previousAdminRole`
      *
      * `DEFAULT_ADMIN_ROLE` is the starting admin for all roles, despite
-     * {RoleAdminChanged} not being emitted signaling this.
+     * {RoleAdminChanged} not being emitted to signal this.
      */
     event RoleAdminChanged(bytes32 indexed role, bytes32 indexed previousAdminRole, bytes32 indexed newAdminRole);
 

contracts/governance/extensions/GovernorTimelockControl.sol

@@ -17,7 +17,7 @@ import {SafeCast} from "../../utils/math/SafeCast.sol";
  * the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be
  * inaccessible from a proposal, unless executed via {Governor-relay}.
  *
- * WARNING: Setting up the TimelockController to have additional proposers or cancellers besides the governor is very
+ * WARNING: Setting up the TimelockController to have additional proposers or cancelers besides the governor is very
  * risky, as it grants them the ability to: 1) execute operations as the timelock, and thus possibly performing
  * operations or accessing funds that are expected to only be accessible through a vote, and 2) block governance
  * proposals that have been approved by the voters, effectively executing a Denial of Service attack.

contracts/interfaces/IERC4626.sol

@@ -198,7 +198,7 @@ interface IERC4626 is IERC20, IERC20Metadata {
     function maxRedeem(address owner) external view returns (uint256 maxShares);
 
     /**
-     * @dev Allows an on-chain or off-chain user to simulate the effects of their redeemption at the current block,
+     * @dev Allows an on-chain or off-chain user to simulate the effects of their redemption at the current block,
      * given current on-chain conditions.
      *
      * - MUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call