Add profile specific caches

[trianglesphere]

Component

Forge

Describe the feature you would like

I'd like the build step in the coverage command to cache the contracts.
forge test does, but forge coverage does not. I understand there is a difference in how the contracts are built between forge test & forge coverage, so it's fine to have separate caches, but it'd be very helpful to have a cache here.

Additional context

No response

[mds1]

You're correct that coverage builds with different settings (no optimizer, no via-ir). So perhaps a more generic feature request here is to automatically have a separate cache per-profile. This way you can maintain performance when switching between profiles without needing to manually set different out-dirs?

Two ideas on how to do this:

1. Change the structure of the out/ dir to include the profile name, so instead of out/Counter.sol/Counter.json it would be out/{profileName}/Counter.sol/Counter.json. This would be a breaking change to scripts that parse the out dir, unless we also maintain the root out/ as containing the most recent build artifacts (i.e. the most recent build artifacts are duplicated/symlinked between out/ and out/{profileName}/
2. Keep the structure of the out/ dir so it only holds the most recent build, but maintain caches in the default cache dir, e.g. ~/.foundry/cache/out/{dirIdentifier}/{profileName}

[trianglesphere]

Out, interesting, different out dirs could be set? I do see how the coverage step doesn't work with pre-building / using a cache.

TBH we've managed to work around this issue & while it seems nice, I don't see it as incredibly important to us.

[zerosnacks]

cc @klkvr besides this being a significant breaking change do you see any blockers on the technical side?

[klkvr]

cc @klkvr besides this being a significant breaking change do you see any blockers on the technical side?

I don't think there are any blockers for separating cache/ and out/, though there will probably be blockers for making this to work for caching coverage compilation data. That's because we are relying on AST IDs in coverage which are getting messed up after incremental builds. This should be possible to handle (e.g. with approach similar to foundry-rs/compilers#140), but might become a blocker once we get to it

[yash-atreya]

cc @klkvr besides this being a significant breaking change do you see any blockers on the technical side?

I don't think there are any blockers for separating cache/ and out/, though there will probably be blockers for making this to work for caching coverage compilation data. That's because we are relying on AST IDs in coverage which are getting messed up after incremental builds. This should be possible to handle (e.g. with approach similar to foundry-rs/compilers#140), but might become a blocker once we get to it

This issue is resolved in #9366 along with enabling caching for coverage.