foundry
foundry copied to clipboard
foundry-rs
Forge coverage compilation fails, while compilation works by itself
Component
Forge
Have you ensured that all of these are up to date?
- [ ] Foundry
- [X] Foundryup
What version of Foundry are you on?
forge 0.2.0 (48d5d79 2022-09-01T00:04:25.075512Z)
What command(s) is the bug in?
No response
Operating System
No response
Describe the bug
We are able to compile our foundry project with forge build
However we are unable to run forge coverage as it throws a compilation error screenshoted below.
What is surprising is that it states solc compilation finished but but still throws a compilation error. Is that some forge internal thing?
IIRC forge coverage requires the optimizer off for source maps to work properly, and I'd guess your forge build has the optimizer on which helps with some stack too deep issues. I'm not sure if there is a workaround for now (maybe via-ir with optimizers off could work for coverage?) so deferring to @onbjerg from here
via-ir with optimzer off doesn't compile either. it gives me the error below:
Compiler run failed
YulException: Variable expr_135_address is 2 slot(s) too deep inside the stack.
What is frustrating is that these stack too deep compiler errors dont give you the line of code where the attempt to use the stack fails.
In any case I presume we wont be able to get this project compiled without using the optimizer. So my question is will the coverage support this eventually?
The optimizer is disabled for coverage because it messes with the source mappings. No real fix for it in mind yet, so it is expected that this happens for some.
Ok so if we want to use forge coverage we need to fix our project to compile without any optimizing flags turned on. For deployment we will still have the optimizer turned on for savings in code size, execution cost etc...
Is there a risk to run your tests again non optimized bytecode and deploy to production with the optimizer on? As in you are not testing the bytecode which will eventually be deployed.
There shouldn't be, no. If the non-optimized bytecode behaves differently compared to the optimized bytecode that is a severe Solidity bug.
anyway thanks we will proceed to run the tests against non optimized solidity compilation and deploy to production with optimizations!
if you're worried about that you can always run tests and coverage as two separate, parallel jobs in ci :) if you use just forge coverage you're probably losing a lot of info - there is no way to use traces etc. currently and i'll likely strip down the options useable on forge coverage
I ran into the same issue today.
What is frustrating is that these stack too deep compiler errors dont give you the line of code where the attempt to use the stack fails.
@FredCoen you can use forge build --contracts=path/to/File.sol to figure out which file is problematic. Set optimizer = false in foundry.toml, and try one by one. When you find it, see which function is mostly likely to have stack too deep (more variables).
Done—known behavior and not too many workarounds—several solutions were provided in the issue.
