diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 49acab231..30c09039e 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -36,7 +36,7 @@ assignees: '' version is bumped to 0.5.0. 5. The 0.5.0 release is made. -This behaviour works well with the :ref:`version pragma `. +This behavior works well with the :ref:`version pragma `. diff --git a/docs/introduction-to-smart-contracts.rst b/docs/introduction-to-smart-contracts.rst index 5595a2fed..c4cc1201b 100644 --- a/docs/introduction-to-smart-contracts.rst +++ b/docs/introduction-to-smart-contracts.rst @@ -564,7 +564,7 @@ contracts, the Ether is forever lost. .. warning:: From version 0.8.18 and up, the use of ``selfdestruct`` in both Solidity and Yul will trigger a - deprecation warning, since the ``SELFDESTRUCT`` opcode will eventually undergo breaking changes in behaviour + deprecation warning, since the ``SELFDESTRUCT`` opcode will eventually undergo breaking changes in behavior as stated in `EIP-6049 `_. .. warning:: @@ -591,7 +591,7 @@ Precompiled Contracts There is a small set of contract addresses that are special: The address range between ``1`` and (including) ``8`` contains "precompiled contracts" that can be called as any other contract -but their behaviour (and their gas consumption) is not defined +but their behavior (and their gas consumption) is not defined by EVM code stored at that address (they do not contain code) but instead is implemented in the EVM execution environment itself. diff --git a/docs/ir-breaking-changes.rst b/docs/ir-breaking-changes.rst index 9cee46793..38e6b552f 100644 --- a/docs/ir-breaking-changes.rst +++ b/docs/ir-breaking-changes.rst @@ -15,13 +15,13 @@ The IR-based code generator was introduced with an aim to not only allow code generation to be more transparent and auditable but also to enable more powerful optimization passes that span across functions. -You can enable it on the command line using ``--via-ir`` +You can enable it on the command-line using ``--via-ir`` or with the option ``{"viaIR": true}`` in standard-json and we encourage everyone to try it out! For several reasons, there are tiny semantic differences between the old and the IR-based code generator, mostly in areas where we would not -expect people to rely on this behaviour anyway. +expect people to rely on this behavior anyway. This section highlights the main differences between the old and the IR-based codegen. Semantic Only Changes diff --git a/docs/metadata.rst b/docs/metadata.rst index c87722bb2..ede16a73f 100644 --- a/docs/metadata.rst +++ b/docs/metadata.rst @@ -147,7 +147,7 @@ explanatory purposes. "useLiteralContent": true }, // Optional: Optimizer settings. The fields "enabled" and "runs" are deprecated - // and are only given for backwards-compatibility. + // and are only given for backward-compatibility. "optimizer": { "details": { "constantOptimizer": false, @@ -241,7 +241,7 @@ relevant part of the bytecode can be decoded with a CBOR decoder. Check the `Metadata Playground `_ to see it in action. Whereas release builds of solc use a 3 byte encoding of the version as shown -above (one byte each for major, minor and patch version number), prerelease builds +above (one byte each for major, minor and patch version number), pre-release builds will instead use a complete version string including commit hash and build date. The commandline flag ``--no-cbor-metadata`` can be used to skip metadata diff --git a/docs/path-resolution.rst b/docs/path-resolution.rst index f63f5e79d..00831e609 100644 --- a/docs/path-resolution.rst +++ b/docs/path-resolution.rst @@ -139,7 +139,7 @@ The initial content of the VFS depends on how you invoke the compiler: #. **Standard input** - On the command line it is also possible to provide the source by sending it to compiler's + On the command-line it is also possible to provide the source by sending it to compiler's standard input: .. code-block:: bash @@ -345,13 +345,13 @@ of the compiler. CLI Path Normalization and Stripping ------------------------------------ -On the command line the compiler behaves just as you would expect from any other program: +On the command-line the compiler behaves just as you would expect from any other program: it accepts paths in a format native to the platform and relative paths are relative to the current working directory. -The source unit names assigned to files whose paths are specified on the command line, however, +The source unit names assigned to files whose paths are specified on the command-line, however, should not change just because the project is being compiled on a different platform or because the compiler happens to have been invoked from a different directory. -To achieve this, paths to source files coming from the command line must be converted to a canonical +To achieve this, paths to source files coming from the command-line must be converted to a canonical form, and, if possible, made relative to the base path or one of the include paths. The normalization rules are as follows: @@ -408,7 +408,7 @@ The resulting file path becomes the source unit name. Prior to version 0.8.8, CLI path stripping was not performed and the only normalization applied was the conversion of path separators. When working with older versions of the compiler it is recommended to invoke the compiler from - the base path and to only use relative paths on the command line. + the base path and to only use relative paths on the command-line. .. index:: ! allowed paths, ! --allow-paths, remapping; target .. _allowed-paths: @@ -421,7 +421,7 @@ locations that are considered safe by default: - Outside of Standard JSON mode: - - The directories containing input files listed on the command line. + - The directories containing input files listed on the command-line. - The directories used as :ref:`remapping ` targets. If the target is not a directory (i.e does not end with ``/``, ``/.`` or ``/..``) the directory containing the target is used instead. @@ -551,7 +551,7 @@ you checked out to ``/project/dapp-bin_old``, then you can run: This means that all imports in ``module2`` point to the old version but imports in ``module1`` point to the new version. -Here are the detailed rules governing the behaviour of remappings: +Here are the detailed rules governing the behavior of remappings: #. **Remappings only affect the translation between import paths and source unit names.** diff --git a/docs/resources.rst b/docs/resources.rst index df0e45019..f51dba4bd 100644 --- a/docs/resources.rst +++ b/docs/resources.rst @@ -23,7 +23,7 @@ Integrated (Ethereum) Development Environments Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine. * `Dapp `_ - Tool for building, testing and deploying smart contracts from the command line. + Tool for building, testing and deploying smart contracts from the command-line. * `Embark `_ Developer platform for building and deploying decentralized applications. diff --git a/docs/smtchecker.rst b/docs/smtchecker.rst index 9c862e530..b68d58ed3 100644 --- a/docs/smtchecker.rst +++ b/docs/smtchecker.rst @@ -97,7 +97,7 @@ Overflow The contract above shows an overflow check example. The SMTChecker does not check underflow and overflow by default for Solidity >=0.8.7, -so we need to use the command line option ``--model-checker-targets "underflow,overflow"`` +so we need to use the command-line option ``--model-checker-targets "underflow,overflow"`` or the JSON option ``settings.modelChecker.targets = ["underflow", "overflow"]``. See :ref:`this section for targets configuration`. Here, it reports the following: @@ -412,7 +412,7 @@ is already "locked", so it would not be possible to change the value of ``x``, regardless of what the unknown called code does. If we "forget" to use the ``mutex`` modifier on function ``set``, the -SMTChecker is able to synthesize the behaviour of the externally called code so +SMTChecker is able to synthesize the behavior of the externally called code so that the assertion fails: .. code-block:: text @@ -750,7 +750,7 @@ and modulo operations inside Horn rules. Because of that, by default the Solidity division and modulo operations are encoded using the constraint ``a = b * d + m`` where ``d = a / b`` and ``m = a % b``. However, other solvers, such as Eldarica, prefer the syntactically precise operations. -The command line flag ``--model-checker-div-mod-no-slacks`` and the JSON option +The command-line flag ``--model-checker-div-mod-no-slacks`` and the JSON option ``settings.modelChecker.divModNoSlacks`` can be used to toggle the encoding depending on the used solver preferences. diff --git a/docs/style-guide.rst b/docs/style-guide.rst index 6173aecc6..266c1817f 100644 --- a/docs/style-guide.rst +++ b/docs/style-guide.rst @@ -28,7 +28,7 @@ captures this concept well. A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important. - But most importantly: **know when to be inconsistent** -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask! + But most importantly: **know when to be inconsistent** -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And do not hesitate to ask! *********** @@ -448,7 +448,7 @@ No: y = 2; longVariable = 3; -Don't include a whitespace in the receive and fallback functions: +Do not include a whitespace in the receive and fallback functions: Yes: diff --git a/docs/types/conversion.rst b/docs/types/conversion.rst index 02b1f2cb9..dafb336bd 100644 --- a/docs/types/conversion.rst +++ b/docs/types/conversion.rst @@ -44,7 +44,7 @@ Explicit Conversions If the compiler does not allow implicit conversion but you are confident a conversion will work, an explicit type conversion is sometimes possible. This may -result in unexpected behaviour and allows you to bypass some security +result in unexpected behavior and allows you to bypass some security features of the compiler, so be sure to test that the result is what you want and expect! diff --git a/docs/types/reference-types.rst b/docs/types/reference-types.rst index 4ba2a65b1..a136497e6 100644 --- a/docs/types/reference-types.rst +++ b/docs/types/reference-types.rst @@ -47,8 +47,8 @@ non-persistent area where function arguments are stored, and behaves mostly like .. _data-location-assignment: -Data location and assignment behaviour -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Data location and assignment behavior +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data locations are not only relevant for persistency of data, but also for the semantics of assignments: @@ -582,10 +582,10 @@ and the assignment will effectively garble the length of ``x``. To be safe, only enlarge bytes arrays by at most one element during a single assignment and do not simultaneously index-access the array in the same statement. -While the above describes the behaviour of dangling storage references in the +While the above describes the behavior of dangling storage references in the current version of the compiler, any code with dangling references should be -considered to have *undefined behaviour*. In particular, this means that -any future version of the compiler may change the behaviour of code that +considered to have *undefined behavior*. In particular, this means that +any future version of the compiler may change the behavior of code that involves dangling references. Be sure to avoid dangling references in your code! @@ -641,7 +641,7 @@ Array slices are useful to ABI-decode secondary data passed in function paramete /// after doing basic validation on the address argument. function forward(bytes calldata payload) external { bytes4 sig = bytes4(payload[:4]); - // Due to truncating behaviour, bytes4(payload) performs identically. + // Due to truncating behavior, bytes4(payload) performs identically. // bytes4 sig = bytes4(payload); if (sig == bytes4(keccak256("setOwner(address)"))) { address owner = abi.decode(payload[4:], (address)); diff --git a/docs/types/value-types.rst b/docs/types/value-types.rst index 872f54b0e..9fcb49b21 100644 --- a/docs/types/value-types.rst +++ b/docs/types/value-types.rst @@ -140,7 +140,7 @@ Exponentiation Exponentiation is only available for unsigned types in the exponent. The resulting type of an exponentiation is always equal to the type of the base. Please take care that it is -large enough to hold the result and prepare for potential assertion failures or wrapping behaviour. +large enough to hold the result and prepare for potential assertion failures or wrapping behavior. .. note:: In checked mode, exponentiation only uses the comparatively cheap ``exp`` opcode for small bases. diff --git a/docs/units-and-global-variables.rst b/docs/units-and-global-variables.rst index a9b29d6ba..e70299679 100644 --- a/docs/units-and-global-variables.rst +++ b/docs/units-and-global-variables.rst @@ -336,7 +336,7 @@ Furthermore, all functions of the current contract are callable directly includi .. warning:: From version 0.8.18 and up, the use of ``selfdestruct`` in both Solidity and Yul will trigger a - deprecation warning, since the ``SELFDESTRUCT`` opcode will eventually undergo breaking changes in behaviour + deprecation warning, since the ``SELFDESTRUCT`` opcode will eventually undergo breaking changes in behavior as stated in `EIP-6049 `_. .. note:: diff --git a/docs/using-the-compiler.rst b/docs/using-the-compiler.rst index d43c78e7c..3ef280a10 100644 --- a/docs/using-the-compiler.rst +++ b/docs/using-the-compiler.rst @@ -54,7 +54,7 @@ or ../ ` are treated as relative to the directories specified us Furthermore, the part of the path added via these options will not appear in the contract metadata. For security reasons the compiler has :ref:`restrictions on what directories it can access `. -Directories of source files specified on the command line and target paths of +Directories of source files specified on the command-line and target paths of remappings are automatically allowed to be accessed by the file reader, but everything else is rejected by default. Additional paths (and their subdirectories) can be allowed via the @@ -114,15 +114,15 @@ Setting the EVM Version to Target ********************************* When you compile your contract code you can specify the Ethereum virtual machine -version to compile for to avoid particular features or behaviours. +version to compile for to avoid particular features or behaviors. .. warning:: Compiling for the wrong EVM version can result in wrong, strange and failing - behaviour. Please ensure, especially if running a private chain, that you + behavior. Please ensure, especially if running a private chain, that you use matching EVM versions. -On the command line, you can select the EVM version as follows: +On the command-line, you can select the EVM version as follows: .. code-block:: shell @@ -227,7 +227,7 @@ Input Description "bzzr://56ab...", "ipfs://Qma...", "/tmp/path/to/file.sol" - // If files are used, their directories should be added to the command line via + // If files are used, their directories should be added to the command-line via // `--allow-paths `. ] // If language is set to "SolidityAST", an AST needs to be supplied under the "ast" key. diff --git a/docs/yul.rst b/docs/yul.rst index 8a500c614..436d0b146 100644 --- a/docs/yul.rst +++ b/docs/yul.rst @@ -960,7 +960,7 @@ the ``dup`` and ``swap`` instructions as well as ``jump`` instructions, labels a .. warning:: From version 0.8.18 and up, the use of ``selfdestruct`` in both Solidity and Yul will trigger a - deprecation warning, since the ``SELFDESTRUCT`` opcode will eventually undergo breaking changes in behaviour + deprecation warning, since the ``SELFDESTRUCT`` opcode will eventually undergo breaking changes in behavior as stated in `EIP-6049 `_. In some internal dialects, there are additional functions: @@ -995,7 +995,7 @@ Its first and only argument must be a string literal and uniquely represents the Identifiers can be arbitrary but when the compiler produces Yul code from Solidity sources, it uses a library name qualified with the name of the source unit that defines that library. To link the code with a particular library address, the same identifier must be provided to the -``--libraries`` option on the command line. +``--libraries`` option on the command-line. For example this code @@ -1076,12 +1076,12 @@ or even opcodes unknown to the Solidity compiler, care has to be taken when using ``verbatim`` together with the optimizer. Even when the optimizer is switched off, the code generator has to determine the stack layout, which means that e.g. using ``verbatim`` to modify -the stack height can lead to undefined behaviour. +the stack height can lead to undefined behavior. The following is a non-exhaustive list of restrictions on verbatim bytecode that are not checked by the compiler. Violations of these restrictions can result in -undefined behaviour. +undefined behavior. - Control-flow should not jump into or out of verbatim blocks, but it can jump within the same verbatim block. diff --git a/tools/yulPhaser/README.md b/tools/yulPhaser/README.md index 3bc72b537..99004d4c9 100644 --- a/tools/yulPhaser/README.md +++ b/tools/yulPhaser/README.md @@ -82,7 +82,7 @@ solc/solc --optimize --ir-optimized --yul-optimizations ### How to choose good parameters Choosing good parameters for a genetic algorithm is not a trivial task but phaser's defaults are generally enough to find a sequence that gives results comparable or better than one hand-crafted by an experienced developer for a given set of programs. The difficult part is providing a fairly representative set of input files. -If the files you give don't need certain optimisations the tool will find sequences that don't use these optimisations and perform badly for programs that could benefit from them. +If the files you give do not need certain optimisations the tool will find sequences that do not use these optimisations and perform badly for programs that could benefit from them. If all the provided files greatly benefit from a specific optimisation, the sequence may not work well for programs that do not. We have conducted [a set of rough experiments](https://github.com/ethereum/solidity/issues/7806#issuecomment-598644491) to evaluate some combinations of parameter values. @@ -91,5 +91,5 @@ The conclusions were used to adjust the defaults but you might still benefit fro 1. The algorithm that performed the best was `GEWEP`. 2. Using longer sequences in the initial population yields better results. The algorithm is good at removing superfluous steps. 3. Preserving the top sequences from previous rounds improves results. Elite should contain at least a few individuals, especially when using the `classic` algorithm. -4. Don't set mutation/deletion/addition chance too high. It makes results worse because it destroys the good patterns preserved by crossover. Values around 1-5% seem to work best. +4. Do not set mutation/deletion/addition chance too high. It makes results worse because it destroys the good patterns preserved by crossover. Values around 1-5% seem to work best. 5. Keep the algorithm running for 1000 rounds or more. It usually finds good sequences faster than that but it can shorten them significantly if you let it run longer. This is especially important when starting with long sequences.