-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Caching not working by default #7379
Comments
hey @onbjerg , I am realizing that I am requesting would it be appropriate to log a message that caching is disabled if |
yeah, it could be, @ClaytonNorthey92 do you have upd: front-ran :) |
@klkvr yes I am just realizing that, mentioned here with a question #7379 (comment) |
Yeah, I think such warning could make sense at least when |
@klkvr also, how do you feel about changing the
and that would disable the reason that I ask is that I am running forge on a code base that I don't own, so I don't want to modify their |
Just want to point out that #7358 causes a significant slowdown in repos that set |
@sam-goldman foundry would not recompile any of the files if them or their imports have not been changed. Thus, unchanged parent contract would not be recompiled. The #7358 was created with idea that expected behavior is to have all sources in build-info which is only possible when no cache is enabled. I feel like we might want to use similar approach as hardhat here: hardhat stores build-info by default on each compiler run and keeps a mapping from contract artifact to build-info file, removing build-info file once no contract are pointing at it. That way, in the case from original issue, latest build info would still only include child contract, but it would be possible to match parent contract to build-info with data for it. This would be a bit hardher to parse, but will be more precise and would not reauire disabling cache. Do you think such UX would make sense @sam-goldman? cc @mattsse |
I started having issues related to cache as I needed both build info and cache files when #7358 hit; it silently disabled cache when build info was set to true (e.g.: it's a requirement for OZ Upgrades Foundry plugin) Cache files - Seems to be needed to run a simple script otherwise, it throws
And if the build info is disabled, the OZ Upgrades can't do all the validations. Quite annoying, activating more build information shall not deactivate the cache; seems very counterintuitive! |
ref foundry-rs/foundry#7379 ref foundry-rs/foundry#4981 ref foundry-rs/foundry#2704 The way Solidity assigns `source_id`s is simply by order in which sources are passed in compiler input. Thus, if we have two sources `A.sol` and `B.sol`, then on the first (non-cached) compiler run, `A.sol` will get assigned ID 1 and `B.sol` will have ID 2. Then, if we change `B.sol` slightly and recompile, it will be the only source in the input, so it will have ID 1. The same ID collisions are more often appearing on multi-version and multi-compiler builds. After many cached runs such discrepancies result in debugger basically displaying random sources. This PR adds a way to link an artifact to the build info for input that produced it, thus allowing us to track correct `source_id -> source` mapping for cached artifacts. I've added `BuildContext` which is the foundry context we are tracking for each compiler invocation. It is getting inlined into `BuildInfo`, and read along with cached artifacts. `BuildContext`s are indexed by the same IDs `BuildInfo`s are, and each `ArtifactId` now has a reference to `build_id` which produced it. Build info now produced on every compiler run, however, it does not include complete input and output unless `project.build_info` is true, to avoid overhead while keeping our internal logic working correctly.
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge 0.2.0 (7545c7a 2024-03-12T00:16:54.294788023Z)
What command(s) is the bug in?
No response
Operating System
Linux
Describe the bug
When running
forge build
twice in a row, with no changes, the previous build isn't cached. This affects other commands as well but is most apparent withbuild
.with an older release
forge 0.2.0 (9f6bb3b 2024-03-11T00:16:01.716842530Z)
, notice that the cache is recognized and build is not repeated.but with
forge 0.2.0 (7545c7a 2024-03-12T00:16:54.294788023Z)
(the buggy version) the build cache is not recognizednote that between running these two commands, I didn't modify any source files.
The text was updated successfully, but these errors were encountered: