Do not run coverage if "--via-ir" is enabled

[PaulRBerg]

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 (d3d8c0b 2022-12-24T12:38:26.644536Z)

What command(s) is the bug in?

forge coverage

Operating System

macOS (Apple Silicon)

Describe the bug

See discussion in #3527, particularly this comment.

If the coverage command is not meant to run over IR-optimized code, I consider it a bug that the coverage implementation does not catch the activation of --via-ir, and does not throw a more specific error to the user.

[Evalir]

happy to take over this! just need confirmation on how we should proceed with the issue, as I will have some time next week.

The steps I see are:

1. Explicitly state that --via-ir can't be used on forge coverage
2. Detect the --via-ir flag either passed in on the command or foundry.toml and throw a more specific error.

[mds1]

If the coverage command is not meant to run over IR-optimized code, I consider it a bug that the coverage implementation does not catch the activation of --via-ir, and does not throw a more specific error to the user.

I'm not sure I follow the bug here. Assuming a user wants to compile/deploy with via-ir, and given that forge coverage requires no optimizer/via-ir and effectively ignores the config file when invoked, there are two scenarios:

1. forge coverage is able to compile normally, so you get coverage results with no via-ir, then deploy with via-ir
2. forge coverage is not able to compile normally, so it exits with an error and you are unable to run coverage

What am I missing here / what is the bug?

[PaulRBerg]

If you don't like the "bug" terminology, I am happy to let go of it in this context.

My point is simply that it would be nice for Forge to give a clearer error when the user attempts to run the coverage command and they have --via-ir enabled.

[mds1]

Do you mean a more clear error when forge coverage fails to compile, or a general message telling users it's ignoring their compilation settings even when successful?

Note that this would also apply when the user doesn't use via-ir, but does use the regular optimizer (i.e. via-ir isn't unique here)

[PaulRBerg]

I mean failing early - not even trying to compile if Forge sees that --via-ir is enabled. Just stop the execution and show an error there.

It is odd that you say that the regular optimizer is not supported, because I have managed to successfully obtain a coverage report even with the optimizer enabled.

[mds1]

It is odd that you say that the regular optimizer is not supported, because I have managed to successfully obtain a coverage report even with the optimizer enabled.

Hmm I think we might be misunderstanding each other a bit here. @mattsse can correct me if I'm wrong but my understanding of forge coverage is it behaves as follows: when you run forge coverage it ignores all solidity build settings you have configured and compiles with default solc settings, i.e. no optimizer and no via-ir.

In your case, it just meant your contracts are able to be compiled both with and without the optimizer.

I mean failing early - not even trying to compile if Forge sees that --via-ir is enabled. Just stop the execution and show an error there.

Say I want to deploy with via-ir because it results in cheaper functions for users. Let's also say my contract still compiles normally, even if via-ir is not used. In this case, why would I want forge coverage to fail early? Getting coverage information is still useful, even though it was compiled differently than the production version will be

[PaulRBerg]

when you run forge coverage it ignores all solidity build settings you have configured

Oh, I didn't know this! Oh my goodness. It all makes sense now. The reason I thought otherwise was because my code used to not compile without --via-ir.

In this case, why would I want forge coverage to fail early?

yeah, you wouldn't want that in this case. As per my explanation above, this was a misunderstanding on my end.

I will close this issue now.

[PaulRBerg]

Thanks a lot for elucidating this issue for me, @mds1!

[mds1]

No problem!