argotorg / argotorg/solidity

Arbitrary order of contracts in override specifier is confusing.

Open
#8,354 18 comments 0 reactions 0 assignees View on GitHub
annoys users :cry: breaking change :warning: low effort low impact must have eventually needs design
Dominant language
C++
Stars
25.7k
Forks
6.2k
Avg merge
2d 19h
Merged PRs (30d)
29

Description

Version: solidity ^0.6.3
Platform: http://remix.ethereum.org/#optimize=false&evmVersion=null&version=soljson-v0.6.3+commit.8dda9521.js

Issue: override(Two, One) doesn't seam to have the intended behavior. Instead, it retains the contract import inheritance.

Example:

```
pragma solidity ^0.6.3;

contract One {
uint256 public a;
event Hah(string message, uint a, uint b);
function foo() virtual public {
a = 1;
emit Hah("One::foo()", a, 0);
}
}

contract Two {
uint256 public b;
event Hah(string message, uint a, uint b);
function foo() virtual public {
b = 2;
emit Hah("Two::foo()", 0, b);
}
}

// Override contract One
contract OneAndTwo is One, Two {
event Hah(string message, uint a, uint b);
function foo() public override(One, Two) {
super.foo();
emit Hah("OneAndTwo::foo() after super.foo()", a, b);
}
}
// Calls Two.foo()

// Swap override contracts
contract OneAndTwoReversed is One, Two {
event Hah(string message, uint a, uint b);
function foo() public override(Two, One) {
super.foo();
emit Hah("OneAndTwoReversed::foo() after super.foo()", a, b);
}
}
// Still calls Two.foo()

// Swap import contracts
contract TwoAndOne is Two, One {
event Hah(string message, uint a, uint b);
function foo() public override(Two, One) {
super.foo();
emit Hah("TwoAndOne::foo() after super.foo()", a, b);
}
}
// Now calls One.foo()
```

Thanks to BokkyPooBah for workshopping this and providing the code examples

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the Solidity ^0.6.3 example in the linked Remix configuration, comparing the three inheritance and override-order cases. Review the compiler behavior for override specifiers and inheritance linearization; done means the intended ordering behavior is agreed and covered by an appropriate regression test or clarified in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
solidity
Domain
blockchain, compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.