-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Requesting bytecode/IR for one contract results in it being generated for all selected contracts #15373
Comments
I can confirm this, but it does not really seem to be a bug, it's more of a limitation of the current design. Not all outputs are generated on-demand - some of them, especially the heavier ones like IR or bytecode, require some upfront work and that work is done in bulk for all contracts even if the output is requested only for one of them. solidity/libsolidity/interface/StandardCompiler.cpp Lines 283 to 299 in 40e005b
So this has nothing to do with the import in your example, but rather with your output selection:
"outputSelection": {
"src/importer.sol": {
"*": [
"abi",
"evm.bytecode",
"evm.deployedBytecode",
"evm.methodIdentifiers",
"metadata"
]
},
"src/contract.sol": {
"*": [
"abi",
"evm.bytecode",
"evm.deployedBytecode",
"evm.methodIdentifiers",
"metadata"
]
}
},
"outputSelection": {
"src/importer.sol": {
"*": [
"abi",
"evm.bytecode",
"evm.deployedBytecode",
"evm.methodIdentifiers",
"metadata"
]
},
"src/contract.sol": {
"*": []
}
}, Both of these currently will perform the same work, the second one will just not output some of the results of that work. That's because I agree that this is not a great design and we should change it. It's technically possible to generate bytecode only for the contracts you request, it will just require changing the way the artifact selection is done in general, which might take some tedious refactoring. |
By the way, do you know of any tool that is actually impacted by it in practice? AFAIK tools typically request the same artifacts for all contracts, which is probably why no one brought this issue up so far. This does have potential to speed things up a lot but only if the compiler is actually being used that way. I'd prioritize this issue higher if you have some evidence that it actually is. |
In Foundry, we erase output selection for contracts which are cached: |
Ok then, in that case it seems worth taking care of sooner rather than later. |
Description
I am attaching 2 standard JSON input files. Both of them include two sources. One of them (
src/contract.sol
) is a Uniswap V3 position manager (can be any contract that takes at least some time to compile). Second is a contract containing a single import directive, importing the heavy contract (import "src/contract.sol";
)In first input, bytecode output selection is requested for both contracts, and in second input - only for the second one.
input1.json
input2.json
Expected behavior
I would expect solc to skip compiling contracts which are excluded from output selection unless they appear as a bytecode dependency (
new
keyword or.creationCode
) in some of the included contracts.Actual behavior
It seems that both inputs take a similar pretty long time to compile event though second input basically just compiles an empty source, and outputs nothing. I assume it spends time compiling imported heavy contract
Fixing this would mean a potentially very high compile time optimization. Right now, even if tooling resolves contract dependecies, and excludes all of them from output selection, solc still spends time compiling and optimizing unused dependencies, even though the resulted bytecode is not outputted at all.
Environment
The text was updated successfully, but these errors were encountered: