-
Notifications
You must be signed in to change notification settings - Fork 794
abigen: ambiguous import of EthCall for inheriting contracts #867
Comments
ah I see, |
I thought it's recommended to bundle them all together to take advantage of the type de-duplication. |
this only provides a benefit if both contracts use the same custom struct types, which are then shared for all contracts, as you can see in your example the perhaps this is ambiguous in the docs |
we don't check if there are calls that are the same |
Ok. I usually need the de-duplication feature. Could the |
the choice to reexport was made to use the types in the same scope the macro is used but I think we could make it public. as a workaround you can do this mod foo {
abigen!(foo...)
}
mod bar {
abigen!(bar...)
} |
should we close this now that #1332 is merged? |
Version
Platform
Linux bix 5.10.90 #1-NixOS SMP Wed Jan 5 11:40:34 UTC 2022 x86_64 GNU/Linux
Description
When a contract inherits from another contract the abigen macro generates one
EthCall
for each function call (with the same name for each contract) and then imports all of them to the top-level. Trying to use...Call
then leads toMy use case is
FunCall::decode(tx.input)
for decoding calldata.To reproduce one can use
and expand the macro or just refer to
FunCall
in code after calling theabigen
macro.Expanded macro:
The text was updated successfully, but these errors were encountered: