Closed vittominacori closed 9 months ago
Whoof! This is definitely me needing to handle the inheritance pattern better. Hopefully, it's just me messing up the ordering of the inheritance statement. The worst-case scenario is a complete disregard for where the specific method name is inherited from.
I'll dig deeper. Thank you for reporting.
After analysis this is definitely the worst-case scenario my "super" keyword decoding in the inheritance tree is extremely dumb! 🙈 I'll fix it, might take a while.
It was a super easy fix after all! 😄 Please try v0.4.10! 🙏
Thank you again!
Thanks. This solved the above issue but I have just another doubt.
Considering the below code (I have more complex contracts inheriting but this should reproduce the issue):
pragma solidity ^0.8.20;
abstract contract Foo {
string private _fooA;
string private _fooB;
constructor(string memory fooA_) {
_setFooA(fooA_);
}
function _setFooA(string memory fooA_) internal {
_fooA = fooA_;
}
function _setFooB(string memory fooB_) internal {
_fooB = fooB_;
}
}
contract MyContract is Foo {
constructor() Foo("A") {
super._setFooB("B");
}
}
Should it say that:
Foo::constructor
-> Foo::_setFooA
MyContract::constructor
-> Foo::_setFooB
This is the output produced and seems that both the calls are inside the Foo constructor.
Am I wrong?
Hi @GNSPS, have you had a chance to look at this behavior?
Thank you for that again. I've taken a look. Released a new version with a fix. v0.4.11. Feel free to try it out.
I'm concerning about the below behavior.
If a contract inherit from multiple contracts, it seems that
graph
insert a method within the wrong contract when that method is called usingsuper.methodName
.Having the code below :
and then using
npx surya graph MyContract.sol | dot -Tpng > MyContract.png
produces the below result
But contract
B
has no methodfooA
.Why is it saying that there is an external call to
B.fooA
? Am I missing something?