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
fix: Enable solc optimization #427
Conversation
Thanks for the PR! I'd be supportive of as many breaking changes around that as you want. So far so good - do you think you'd want to merge as-is, or do you want to add additional stuff? |
My preference would probably be to have This would break things that previously used What do you think about also taking arbitrary string args the way ganache does? ethers-rs/ethers-core/src/utils/ganache.rs Lines 122 to 126 in 584b683
|
Both Option and arbitrary string args SGTM! |
Change optimizer() method to accept an Option<usize> (breaking). Add args() option to pass arbitrary arguments to solc command.
The breaking change here is that The other addition is
Probably the output parsing could be made more general, but at some point it's easier to just build the command and handle the output yourself. // No optimization
let contracts = Solc::new("./contracts/*")
.optimizer(None)
.build()?;
// Some(200) is default, optimizer on with 200 runs
// .arg() allows passing arbitrary args to solc command
let optimized_contracts = Solc::new("./contracts/*")
.optimizer(Some(200))
.arg("--metadata-hash=none")
.build()?; TestsThis could use some, but I'm not sure the most robust way to test Solc given that it's all reliant on the locally installed version. |
there's an issue with Address::zero() being used as a default in clap ❯ forge test error: Invalid value for '--tx-origin <TX_ORIGIN>': Invalid character '…' at position 4
Motivation
Currently, the solc bindings ignore the
optimizer
parameter.Solution
Add the optimization arguments to the executed command.
This also adds some options around using the optimizer, some of which may be a little awakward as implemented. Ideally, in addition to enabling the optimizer, users should be able to:
As implemented, the current examples will work as expected (with optimization now).
However, the optimizer no longer defaults to the optimizer ON with 200 runs (which is what the documentation used to suggest). Also, you now need to know the runs parameter you want to use in order to enable optimization.
Alternatively, we could add a
.optimize(bool)
method, with the downside just being verbosity. If a breaking change was acceptable,optimizer()
could take anOption<usize>
.PR Checklist