build info caching leaves stale build info files on disk

[0xalpharush]

Now that build-info is being cached in foundry, all old build info's under out/build-info are left on disk even after recompiling. Could they be merged into one valid, current build info for the given compilation unit?

For instance, ls out/build-info will accumulate new entires each time I edit a file:

6d5ba56c654d768d5bf8d51bbc3c7e34.json c1f9db2b3d661b08e8fe8c097f2fdad8.json f2030736ea49b0ca4a5709ec90d5910d.json

These also appear in cache/solidity-files-cache.json:

    "builds": [
        "6d5ba56c654d768d5bf8d51bbc3c7e34",
        "c1f9db2b3d661b08e8fe8c097f2fdad8",
        "f2030736ea49b0ca4a5709ec90d5910d"
    ]

Instead, I would expect that there is one build info on disk (assuming one compilation unit) which consists of the aggregate artifacts of the most recent, solidity files still on disk. Otherwise, there is not really a great way to tell whether there are multiple compilation units or if the build info entry is a newer version of a previous entry

I think they could be merged here but lmk if another approach is more desirable

compilers/crates/compilers/src/cache.rs

Line 894 in b04423c

let cached_builds = cache.read_builds(&project.paths.build_infos).unwrap_or_default();

xref foundry-rs/foundry#8164
xref #140

[klkvr]

After #177 all build infos stored on disk are guaranteed to be referenced by at least one cached artifact, and they will be removed once no artifacts are pointing to them.

However, I think we'd keep approach with separate file per compiler run as fitting all this info into single file wouldn't be any different and will just result in enormous file sizes. Hardhat uses same approach so I assumed that it might also be easier to adapt for existing tooling

[0xalpharush]

Will cached artifacts have the same build id as their freshly compiled counter parts or they will both have different id's?

I was speaking of the case where there is one compilation unit (a group of source units compiled with the same compiler settings that may reference each other e.g. in imports irregardless of whether cached artifacts are used to create the build info).

Hardhat always creates one build file in this case to my knowledge and we've never had any issues supporting that bc there is a unique compilation id (the name of the build file) and it's complete i.e. we don't have to track down artifacts across files.

If something different is going to be done, IMO this should have been treated as a breaking change and not considered as the hardhat format anymore (please bump the _format and communicate that there is an upcoming change so downstream users can prepare)

[0xalpharush]

For background on multiple compilation units, it would be worth revisiting this for features like #170