Skip to content
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(config): allow overriding solc settings per contract #7720

Closed
mds1 opened this issue Apr 19, 2024 · 4 comments · Fixed by #8668
Closed

feat(config): allow overriding solc settings per contract #7720

mds1 opened this issue Apr 19, 2024 · 4 comments · Fixed by #8668
Labels
A-compiler Area: compiler A-config Area: config T-feature Type: feature
Milestone

Comments

@mds1
Copy link
Collaborator

mds1 commented Apr 19, 2024

Component

Forge

Describe the feature you would like

The main use case for this is when one contract is close to the size limit—compile the large contract with 1 optimizer run (which minimizes code size) and compile the rest with larger values of optimizer runs.

In #3062 we were tracking this and had a potential UX but that issue was closed by the inline config PR, so I think we lost track of this feature request? Either way, the idea was :

# In our default solidity profile we apply 10M optimizer runs.
[profile.default.solidity]
optimizer = true
optimizer-runs = 10_000_000

# But we have one really big contract, so we use 1 optimizer run to minimize
# its size.
[profile.default.solidity.minimize_size]
optimizer = true
optimizer-runs = 1
match-contract = "MyBigContract" # all match flags supported

Hardhat has supported this for a long time, as seen here:

module.exports = {
  solidity: {
    compilers: [...],
    overrides: {
      "contracts/Foo.sol": {
        version: "0.5.5",
        settings: { }
      }
    }
  }
}

Additional context

No response

@mds1 mds1 added T-feature Type: feature A-compiler Area: compiler labels Apr 19, 2024
@jubeira
Copy link

jubeira commented Apr 25, 2024

This would be great.

There are a lot of settings that affect compile time (e.g. via_ir flag) that make development easier in some cases, but applying them to every contract becomes a huge pain in terms of performance. Being able to isolate these settings to specific contracts would be awesome.

@sakulstra
Copy link
Contributor

would it be possible to also support this inline (like on #3062) opposed to on foundry.toml?

@jubeira
Copy link

jubeira commented May 9, 2024

I'd like to rephrase #7720 (comment).

via_ir seems to be superior in every sense compared to the default pipeline: it produces denser bytecode, lower gas costs, and less frequent stack-too-deep issues. The only reason we are not using it as a default in our project is because compiling every contract (including forge tests) with the flag becomes painfully slow, making the dev UX pretty bad.

We don't care that much about gas savings and bytecode for tests, but having to deal with stack-too-deep issues just to be able to run the tests faster while it could be solved turning on a flag is far from optimal.

Having this feature would allow using via_ir as default just for the contracts that really need it without impacting the compile time for the tests. This would have a great impact on code quality, requiring less unnecessary effort dealing with stack too deep, and also allowing to execute the tests with the actual artifacts that will eventually be deployed to production. In our case at least it'd have a huge impact.

@zerosnacks zerosnacks added the A-config Area: config label Jul 15, 2024
@zerosnacks zerosnacks changed the title feat: allow overriding solc settings per contract feat(config): allow overriding solc settings per contract Jul 15, 2024
@zerosnacks zerosnacks added this to the v1.0.0 milestone Jul 26, 2024
@grandizzy
Copy link
Collaborator

this looks like it will be solved when PR #8668 ready and merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiler Area: compiler A-config Area: config T-feature Type: feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants