-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: compilation restrictions #8668
Conversation
Not sure if it's related to this or some other unreleased code, but on this branch I've noticed some behaviour where |
## Description As I told some of you at dinner, I've had a bad case of insomnia over the last week. This PR resulted from a couple of late night coding sessions and the incessant need to make things nicer in our repos. It's a big PR but 𝚫code is negative so 🤷 . What happens in this mondo-PR: 1. All `celo` contracts are removed form the repo and replaced with the `@celo/contracts` NPM package. With a small caveat. 2. All `interfaces` are made to work with `0.8` and cover more of the contract functions. 3. All `tests` contracts are updated to `0.8` and use `deployCode` helpers to deploy lower-version contracts, and the use the interfaces to interact with them. 4. ~We make use of this foundry-rs/foundry#8668 to improve compile time.~ 5. Update `solhint` and `prettier` to a recent version and fix/ignore all issues. 6. Fix solc compiler warnings. 7. Fix/ignore slither > informational warnings. 8. Slight Refactor of ForkTests to make them better to work with. 9. Restructuring of the tests folder. #### `@celo/contracts` The only caveat of using the `@celo/contracts` package is that `UsingRegistry.sol` in there needs to import things from `mento-core` and I didn't manage to get it working ok with remappings, so I kept a copy of `UsingRegistry.sol` in `contracts/common`. It's only used in `swap/Reserve.sol` and when we remove it from there we can completely kill `common`. #### The foundry WIP PR A better solution was found here #502, which removes the need for `via-ir` completely. ~The reason it takes so long to compile our code is because we need `via-ir` for `Airgrab.sol` and `StableTokenV2.sol`, and `via-ir` is super slow. But with the compiler restrictions implemented in foundry-rs/foundry#8668 we can have multiple compiler profile settings for subgraphs of the source-graph, which compile in parallel with different settings.~ ~You can easily install that version of foundry locally, (you have to have rust installed tho):~ ``` foundryup -P 8668 ``` ~With this version of foundry and the settings in `foundry.toml`, if you're not working in a part of the source graph that contains `Airgrab.sol` or `StableTokenV2.sol`, compilation will happen without `via-ir` and will be super snappy. However if you do touch that source graph it will still take noticeably long. Right now on my machine full clean compilation takes 80seconds. It used to take >3minutes.~ #### ForkTest Refactoring Our fork tests can get a bit heavy because they're running test assertions for all the exchanges in a single test call. I've refactor it a bit and split out exchange assertions into their own tests contracts that need to be manually created when new exchanges are deployed. There's a chain-level assertion on the number of exchanges that helps us catch this and keep them up to date. This work was continued here #503 for a much cleaner solution. ### Other changes > _Describe any minor or "drive-by" changes here._ no minor changes here, no :)) ### Tested Tested? Tested! ### Related issues Fixes the issues in my head. ### Backwards compatibility What even is that? ### Documentation Holy Bible --------- Co-authored-by: Bayological <6872903+bayological@users.noreply.github.com> Co-authored-by: chapati <philip.paetz@me.com> Co-authored-by: philbow61 <80156619+philbow61@users.noreply.github.com>
40c8e58
to
ecb767d
Compare
it doesn't. Each project file would still get compiled with either default or custom profile unless you specify |
Thanks for the reply. Can you please point me to the config key that can be used to dictate which artifacts would get included? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, optional suggestions
optimizer_runs: Option<usize>, | ||
max_optimizer_runs: Option<usize>, | ||
|
||
#[serde(default, with = "serde_helpers::display_from_str_opt")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated,
worth checking which of the serde_utils we'd like to have in alloy-serde
* [wip] feat: compilation restrictions * Cargo.lock * update patch * fixes * update patch * update patch * wip * deps * bytecode hash * fixes * rm patches * pub
@klkvr Could you please help describe the behaviour when setting min_solc_version | max_solc_version ? Here's a sample repo: Which as it stands uses 0.8.19 for all Behaviour I would like:
It's also not clear to me what |
hey @frontier159
compilation_restrictions = [
{ paths = "src/Counter-0.8.19.sol", version = ">=0.8.19, <=0.8.22" },
]
So for this example if you only need to specify the version restrictions you can just not add any profiles, the |
@klkvr In this example repo, if I set to:
Then I get the error:
Sorry I might need to be spoon fed with the full example |
you need to remove the |
So how do I fully specify that |
something like this should work [profile.default]
src = "src"
out = "out"
libs = ["lib"]
compilation_restrictions = [
{ paths = "src/**[!1][!9].sol", version = "=0.8.22" },
{ paths = "src/Counter-0.8.19.sol", version = "=0.8.19" },
] we don't yet have full regex support for glob patterns, so the first restriction is a bit ugly, you could use a separate directory for this to make it nicer |
OK great thanks @klkvr It would be nice to still be able to specify the default version for any unmatched paths (eg via It will get complicated if we have more than one or two upstream dependencies (eg in libs or node_modules) which need specific versions but then for everything else we want to specify the version. eg
Alternatively implement where the order matters, where if a file is matched in an earlier list item it it won't be matched in future ones, so where this could work:
|
Closes #6099
Closes #5715
This builds on top of foundry-rs/compilers#170 and allows the following configuration options in foundry.toml:
compilation_restrictions
allows users to configure how we compile individual files or directories. Currently accepted keys aremin_evm_version
,max_evm_version
,min_optimizer_runs
,max_optimizer_runs
,cancun
. Configured restrictions apply to sources importing the restricted file as well.Once we have a set of restrictions, we need to somehow construct settings objects to satisfy them. Right now those should be constructed manually via
additional_compiler_profiles
. It is configured a mapping from profile name to settings overrides. In example above we add a single profile namedvia-ir
, which uses default settings withvia_ir
enabled, making it possible to compile a single contract undersrc/
with via-ir while all other contracts, including tests are compiled with default profile.We need names for all profiles to include them into artifacts names in cases when same source file is compiled with multiple different profiles. Right now such artifacts would be named as
Counter.{profile}.json
.When choosing profile, first profile (starting with default one), satisfying restrictions of the source file and all of its imports will be used.