-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
contractDependencies
in the AST no longer includes inherited contracts on 0.8.4+
#11643
Comments
Contract dependencies only contain contracts that are created via 'new' or contracts whose bytecode is referenced, not contracts that are inherited. Can someone please check if we can improve the documentation around this? |
Wait, so this isn't a bug? It seems it was functionality removed from previous versions. Or are you saying that this feature should never have been in past versions in the first place? |
Yes, the meaning of the field was always intended to be "These contracts need to be compiled first in order to compile the current contract". You can follow the inheritance pointer if you want to get a list of contracts that includes base contracts in addition to that. |
Ah. So where can we see contract dependencies that are inherited? Is this "inheritance pointer" in the output of the I'm asking because as part of a verification script, we were using the |
The type of code that still works with flattened source gets less and less. We are almost at a point where I would say that flattening is a security risk. If you want to extract all source code that is needed to compile a contract, you also have to include structs, libraries, file-level functions and so on. For completeness: The base contracts of a contract can be found in the AST under the key "baseContracts" - the full hierarchy in "linearizedBaseContracts". |
Thanks for the tips. We don't deploy flattened code, but use it for verification. I found the keys you're referring to. So ideally the way to "flatten" the code would be to iterate through the baseContracts and linearizedBaseContracts and import the code accordingly? Or are you saying to not flatten at all, or there might be a better verification method? |
I'm saying not flatten at all. Don't throw away the metadata file and you have every single bit you need for verification. Do you know https://sourcify.dev/ ? |
Where you do you verify? Etherscan? They support standard-json - if you don't use any framework that verifies for you on etherscan then please take a look at that. |
1 similar comment
Where you do you verify? Etherscan? They support standard-json - if you don't use any framework that verifies for you on etherscan then please take a look at that. |
Yeah I'm using brownie, and recently their verifier relied on the Sounds like |
AFAIK Brownie itself uses The only thing to watch out for would be to make sure that the JSON does not contain any absolute paths so make sure you only use relative paths when using remappings to make importing from external packages work. |
Hmm... Last I checked it looked like it was flattening source code instead of using standardjson. It looks like it would be pretty easy to refactor for this though. Thanks for the tips! But yes, would love to see some more docs on this. |
To be clear, I mean that Brownie is using Standard JSON for compilation. I thought you were trying to build the verification input yourself based on compiler's output and side-step is verification tool. This is why I'm suggesting to use Standard JSON instead. Disappointingly, looks like Brownie had a feature request to implement verification with several competing PRs and for some reason they went with the one that uses the less robust, flattening approach (eth-brownie/brownie#411 (comment), PR: eth-brownie/brownie#914). So if you're actually trying do it through Brownie's tool, it looks like you might be forced to flatten. |
I have just stumbled upon #121, and I wonder if this shouldn't have been treated as a breaking change after all. /// List of contracts this contract creates, i.e. which need to be compiled first.
/// Also includes all contracts from @a linearizedBaseContracts.
std::set<ContractDefinition const*> contractDependencies; It was just an internal comment and the AST structure is not documented yet, so technically we did not guarantee that but some tools were clearly depending on it. |
^^^ |
contractDependencies
in the AST no longer includes inherited contracts on 0.8.4+
Hi everyone! This issue has been closed due to inactivity. |
Description
Dependencies of contracts are not being properly recorded in the compiler.
Environment
Steps to Reproduce
input.json
cat input.json | solc --standard-json
Copy the output, it'll look like:
If we look at
contractDependencies
we can see that the list is blank. This is incorrect, asDummyVersion8Contract
importsImportMev8.sol
and uses a function from it.If you run the same process with
v0.8.3
of solidity, we do not get this error.Can we please address?
The text was updated successfully, but these errors were encountered: