Why force turning off solc optimizer in 0.7.0 beta?

[boolafish]

Hi, recently somehow I get a code that can only compile with optimizer on 😓😓😓

But anyway, just realized that during the coverage, it actually force flagging the using optimizer flag to false: https://github.com/sc-forks/solidity-coverage/blob/beta/dist/truffle.plugin.js#L92

Is there a reason to do so? Also, shall we also just keep in mind that the coverage would always be running without optimizer on?

[cgewecke]

@boolafish Yes, the optimizer is turned off because the tool instruments Solidity by injecting small no-op statements which optimization might remove.

Can you link to the code which only compiles w/ optimization on?
Why does it not work when optimization is off?

[cgewecke]

omgnetwork/plasma-contracts@90d8826

[boolafish]

Yeah, the above link is the fix on my side.
If you're interested, I put a problem-ish branch on my fork:

branch: fail_with_optimizer_off
latest commit with some observation of mine: here

[cgewecke]

@boolafish Ah that's really interesting thank you.

I think the coverage tool should probably try to be clearer about what the compilation settings are in the docs and terminal output. There are probably more cases like this....

[superduck35]

fwiw, I also had this issue and was lucky to search through existing issues on here for an answer. It's a hard one to communicate to the user, but yeah I think just being clearer about what the compilation settings are is a step in the right direction. Not sure why my method execution fails when optimisation is disabled though :)

[cgewecke]

@alsoc77 Out of curiosity - what is your compilation error message? Is the code where youre seeing this public?

[cgewecke]

For context @boolafish's error is

"Assembly exception for bytecode"

which looks like a internal solidity crash... I wonder if these incidents should be collected and reported to solc.

[superduck35]

My scenario is a bit tricky to disect. I did end up figuring out a solution though.
I have a ContractFactory that has a createContract func in which it deploys a new , and there was an issue in the bytecode of the constructor of the child that was causing a revert. One of the libraries that was linked to this child was using an external contract that hadn't been deployed, rather than referencing an interface of this contract.
So the solution was to create a local interface for this external contract.
I suspect the optimizer was figuring out what part of the external contract it needed, then just slicing that bit off and putting it in, whereas an unoptimized compilation was attempting to do something else.
Anyway, thanks for this. Love the plugin -- really appreciate the Istanbul reporting, thanks @cgewecke

[Ferparishuertas]

CompileError: CompilerError: Stack too deep when compiling inline assembly: Variable headStart is 1 slot(s) too deep inside the stack.

With optimizer it works.

It's a bunch of smart contracts with AbiEncoderv2 using structs as params and return values

Any idea how to make coverage work?

Solc 7.1

[cgewecke]

@Ferparishuertas

No, sorry. Thanks for reporting this.

I think these cases should be raised at ethereum/solidity if it's possible to generate minimized reproductions for them. It seems strange that optimization would affect whether or not compilation succeeds.

[Ferparishuertas]

Will definetly do it. Any contract over 24k, with Abiv2encoder raises this problem with optimizer=false

[AndonMitev]

So guys do you came up with any solution about the
CompilerError: Stack too deep when compiling inline assembly: Variable value0 is 1 slot(s) too deep inside the stack. Error.
Yes I'm using optimizer ON on hardhat config settings, but not able to run my coverage, is there anyway to turn it on in the plugin as well?

[cgewecke]

@AndonMitev No, haven't found a solution. This is an open issue about this at solidity 10354. If I understand the maintainer's comments there correctly, this is a known limitation of the solidity compiler and AbiEncoderV2.

Out of curiosity, which compiler version are you using?

One resource you might look at it is the argentlabs Filter for Paraswap V4 cross link just above in this thread. There's an explanation of how they restructured their contracts to get around this problem in that PR.

[AndonMitev]

@AndonMitev No, haven't found a solution. This is an open issue about this at solidity 10354. If I understand the maintainer's comments there correctly, this is a known limitation of the solidity compiler and AbiEncoderV2.

Out of curiosity, which compiler version are you using?

One resource you might look at it is the argentlabs Filter for Paraswap V4 cross link just above in this thread. There's an explanation of how they restructured their contracts to get around this problem in that PR.

version: '0.7.3',

[abdulsamijay]

Hey all,
Have we found a solution or a work-around to this ? I cant get coverage to run as it does not compile with optimizer on. I am facing the same issue as @AndonMitev
CompilerError: Stack too deep when compiling inline assembly: Variable value0 is 1 slot(s) too deep inside the stack. Error.

[JasoonS]

BTW, I got it fixed and working here: https://npmjs.com/package/@float-capital/solidity-coverage

Hopefully will be up-streamed soon #642 👍 You can test it in the interim.

Simply install the package and change the following in your hardhat.config.js:

-require("solidity-coverage");
+require("@float-capital/solidity-coverage");

[TheBlockchainAuditor]

BTW, I got it fixed and working here: https://npmjs.com/package/@float-capital/solidity-coverage

Hopefully will be up-streamed soon #642 +1 You can test it in the interim.

Simply install the package and change the following in your hardhat.config.js:

-require("solidity-coverage");
+require("@float-capital/solidity-coverage");

This worked for me but I had to set my hardfork to berlin!

Thanks JasoonS!!

[cgewecke]

Closing this for housekeeping. v0.8.7 now supports viaIR natively. While the optimizer is usually. turned off, if viaIR is enabled it allows optimization.