-
Notifications
You must be signed in to change notification settings - Fork 44
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
feat: track and cache context of each compiler invocation #140
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this makes a lot of sense and this approach works afaict
only have a pedantic nit,
can we do a foundry companion before merging?
src/compile/output/mod.rs
Outdated
/// A mapping from build_id to [BuildContext]. | ||
pub type Builds<L> = BTreeMap<String, BuildContext<L>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer a wrapper type for this, just because aliases for maps are not great imo
we can add "Unicode-3.0" to allowed in deny.toml |
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 sourcesA.sol
andB.sol
, then on the first (non-cached) compiler run,A.sol
will get assigned ID 1 andB.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 intoBuildInfo
, and read along with cached artifacts.BuildContext
s are indexed by the same IDsBuildInfo
s are, and eachArtifactId
now has a reference tobuild_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.