diff --git a/ReviewChecklist.md b/ReviewChecklist.md index 35563d890712..e75b551410d9 100644 --- a/ReviewChecklist.md +++ b/ReviewChecklist.md @@ -146,7 +146,7 @@ The following points are all covered by the coding style but come up so often th - [ ] Attached library functions? Functions attached with `using for`? - [ ] Possible combinations of `storage`, `memory`, `calldata`, `immutable`, `constant`? Remember that internal functions can take `storage` arguments. - - [ ] Does it work at construction time as well? What if you store it at construction time and read after deployment? + - [ ] Does it work at construction time as well? What if you store it at construction time and read it after deployment? - [ ] What about importing it from a different module or inheriting it? - [ ] Have you tested it with the ternary operator? @@ -155,7 +155,7 @@ The following points are all covered by the coding style but come up so often th When checking if we have the case already covered the name is usually the only clue we see. - [ ] Place them in the right subdirectory. - [ ] **Avoid simply appending numbers to the name to distinguish similar cases.** - Coming up with good names is hard but figuring out if any of hundreds of tests with names that + Coming up with good names is hard but figuring out if any of the hundreds of tests with names that match your search actually fits your case is even harder. - [ ] **Do not include version pragma and the SPDX comment in semantic and syntax test cases**. In other test types include them if necessary to suppress warnings. diff --git a/docs/050-breaking-changes.rst b/docs/050-breaking-changes.rst index a40bbcf6e9d8..3952ced47186 100644 --- a/docs/050-breaking-changes.rst +++ b/docs/050-breaking-changes.rst @@ -19,7 +19,7 @@ Semantic Only Changes ===================== This section lists the changes that are semantic-only, thus potentially -hiding new and different behavior in existing code. +hiding new and different behaviors in existing code. * Signed right shift now uses proper arithmetic shift, i.e. rounding towards negative infinity, instead of rounding towards zero. Signed and unsigned @@ -212,7 +212,7 @@ Conversions is now disallowed. * Explicit and implicit conversions from hex literals to ``bytesXX`` types - of different size is now disallowed. + of different sizes is now disallowed. Literals and Suffixes --------------------- diff --git a/docs/060-breaking-changes.rst b/docs/060-breaking-changes.rst index e7c93057f62a..b1d7fd3430b3 100644 --- a/docs/060-breaking-changes.rst +++ b/docs/060-breaking-changes.rst @@ -15,7 +15,7 @@ Changes the Compiler Might not Warn About This section lists changes where the behavior of your code might change without the compiler telling you about it. -* The resulting type of an exponentiation is the type of the base. It used to be the smallest type +* The resulting type of exponentiation is the type of the base. It used to be the smallest type that can hold both the type of the base and the type of the exponent, as with symmetric operations. Additionally, signed types are allowed for the base of the exponentiation. @@ -78,7 +78,7 @@ and it does something else afterwards. * If present, the receive ether function is called whenever the call data is empty (whether or not ether is received). This function is implicitly ``payable``. - * The new fallback function is called when no other function matches (if the receive ether + * The new fallback function is called when no other function matches (if the received ether function does not exist then this includes calls with empty call data). You can make this function ``payable`` or not. If it is not ``payable`` then transactions not matching any other function which send value will revert. You should only need to diff --git a/docs/080-breaking-changes.rst b/docs/080-breaking-changes.rst index 9d1f3347b6b2..51afb7a64259 100644 --- a/docs/080-breaking-changes.rst +++ b/docs/080-breaking-changes.rst @@ -40,7 +40,7 @@ the compiler notifying you about it. More specifically, they will use error data equal to a function call to ``Panic(uint256)`` with an error code specific to the circumstances. - This will save gas on errors while it still allows static analysis tools to distinguish + This will save gas on errors while it still allowing static analysis tools to distinguish these situations from a revert on invalid input, like a failing ``require``. * If a byte array in storage is accessed whose length is encoded incorrectly, a panic is caused.