Solidity-coverage: 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 :sweat::sweat::sweat:

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]

https://github.com/omisego/plasma-contracts/pull/328/commits/90d88261d1f0822e28a6b2a30c7580364728e318

[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....

[alsco77]

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.

[alsco77]

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