bug(`forge coverage`): stack too deep when using `--ir-minimum` and coverage report is not accurate

[uranium93]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (ddaf100 2022-09-24T00:05:44.382307Z)

What command(s) is the bug in?

forge coverage

Operating System

macOS (Apple Silicon)

Describe the bug

on executing forge coverage i am getting the below error

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

but forge test and forge build are working fine.

NOTE: I noticed also that forge build and forge test are considering the cache but forge coverage is trying to re-compile even though I have a cached successful build

[Rubilmax]

Hi @onbjerg @mattsse, do you have any lead on this?

The bug also happens to us @ Morpho Labs

[mds1]

AFAIK forge coverage currently compiles with the optimizer off, which is needed for better source maps. forge test (and build) work because you're using the optimizer or via-IR which resolve the stack too deep error that's occurring with the optimizer off (this is also why you see it recompile for coverage).

Unfortunately for now to use coverage you'll need to refactor such that you can compile with the optimizer off / without via-IR

[Rubilmax]

Understood, thanks! Is this issue thus nullified?

Would it be possible to have more information on where the Stack Too Deep error occurs in the source code pls?

[mds1]

Is this issue thus nullified?

I think this is a question for @uranium93? But yes I'd say this is a known issue/limitation so we can close this

Would it be possible to have more information on where the Stack Too Deep error occurs in the source code pls?

Unfortunately not, as solc does not provide this information since it's complex to retrieve. You can read more here: argotorg/solidity#11638 (comment)

[Rubilmax]

Thank you!

[emo-eth]

I understand the reasoning for compiling without the optimizer – but I will note that this means currently any project that imports Seaport contracts directly cannot use forge coverage, as some assembly results in stack-too-deep errors.

There's probably not much to do at the moment – but we'd love if we could encourage new projects to build on top of Seaport with Foundry (including coverage) in the future.

[uranium93]

Hey @Rubilmax , for me the only fix that was possible and fast is to re-write the affected tests with hardhat

[PaulRBerg]

@uranium93 structs are a neat way to solve Stack Too Deep.

[FlokiBB]

Hi Matt, is this issue still unresolved? I would be happy to work on it.

@mds1