From ed74ad9a4127c09686e0bc1982f2a14b5de4bfdb Mon Sep 17 00:00:00 2001 From: Danbo <140512416+dannbbb1@users.noreply.github.com> Date: Wed, 18 Dec 2024 10:03:23 -0500 Subject: [PATCH 1/2] Update CODING_STYLE.md --- CODING_STYLE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CODING_STYLE.md b/CODING_STYLE.md index 2305ae1ec752..dc2a24f55a8b 100644 --- a/CODING_STYLE.md +++ b/CODING_STYLE.md @@ -107,7 +107,7 @@ Use `solAssert` and `solUnimplementedAssert` generously to check assumptions tha 1. {Typename} + {qualifiers} + {name}. 2. Only one per line. 3. Associate */& with type, not variable (at ends with parser, but more readable, and safe if in conjunction with (b)). -4. Favour declarations close to use; do not habitually declare at top of scope ala C. +4. Favor declarations close to use; do not habitually declare at top of scope ala C. 5. Pass non-trivial parameters as const reference, unless the data is to be copied into the function, then either pass by const reference or by value and use std::move. 6. If a function returns multiple values, use std::tuple (std::pair acceptable) or better introduce a struct type. Do not use */& arguments. 7. Use parameters of pointer type only if ``nullptr`` is a valid argument, use references otherwise. Often, ``std::optional`` is better suited than a raw pointer. From fd292cdbca626d3631f9dd3786f59d6fd9a545ee Mon Sep 17 00:00:00 2001 From: Danbo <140512416+dannbbb1@users.noreply.github.com> Date: Wed, 18 Dec 2024 10:06:01 -0500 Subject: [PATCH 2/2] Update README.md --- tools/yulPhaser/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/yulPhaser/README.md b/tools/yulPhaser/README.md index 99004d4c93cc..bb638594a3e4 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 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 the files you give do not need certain optimizations the tool will find sequences that do not use these optimizations 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.