Skip to content
This repository has been archived by the owner on Aug 5, 2021. It is now read-only.

etherlime flatten overloads node.js #322

Closed
elenadimitrova opened this issue Apr 10, 2020 · 6 comments
Closed

etherlime flatten overloads node.js #322

elenadimitrova opened this issue Apr 10, 2020 · 6 comments

Comments

@elenadimitrova
Copy link

etherlime flatten overloads node.js and doesn't complete running.

You can reproduce with argent-contracts repo by running etherlime flatten modules/TransferManager.sol there.

@desimira
Copy link
Contributor

desimira commented Apr 10, 2020

Hi, Elena! I spent some hours to figure out what causes your problem and it seems that you are importing BaseWallet.sol in Module.sol and then also importing Module.sol in BaseWallet.sol. The flattener embeds the source code of all imported files first and and at the end the content of the main contract. In this scenario it could not record neither the BaseWallet.sol nor Module.sol (it's some kind of recursion because it would always try to record the imported file first).
The content of imported contracts must be before the content of the main one, otherwise it would throw an error that can not find the resource when trying to compile the flattened .sol.

I haven't gotten into the logic of your contracts, so I don't know whether importing the contracts each other is what you really need.

I'll be glad to help if needed :)

@elenadimitrova
Copy link
Author

I see, but the problem is that this is valid Solidity which does support such circular dependencies. This is considered safe because neither is inheriting from the other. It's also not a good practice to iterate through the imports sequentially as when imports are repetitive, there'll be duplicated contract code in the flattened version in addition to problems like the above. Logically it seems that a superset of all imports should be composed first and then their source pulled into the flat contract.

@desimira
Copy link
Contributor

Hey, Elena! We've just released new version of etherlime and it should fixes the issue. I've totally rewrote the flattener algorithm so it allows now circular dependencies. Hope that would be useful for you! :)

@elenadimitrova
Copy link
Author

I'm still getting the same behaviour with 2.3.3 :(

@desimira
Copy link
Contributor

desimira commented May 4, 2020

I have tested with the repo you provided and it was able to flatten the TransferManager contract. Just to be sure, can you check with etherlime --version?

@elenadimitrova
Copy link
Author

elenadimitrova commented May 5, 2020

Sorry @desimira my mistake, I was running a different install globally. Confirming this works now. Thanks for implementing the logic!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants