Fix segfault when emiting warning for empty contracts with custom layout near the end of storage#16682
Conversation
5988dfb to
2f481bc
Compare
msooseth
left a comment
There was a problem hiding this comment.
LGTM, but I am bad at reviews.
2f481bc to
263706a
Compare
| for (ContractDefinition const* baseContract: ranges::actions::reverse(_contract.annotation().linearizedBaseContracts)) | ||
| for (VariableDeclaration const* stateVariable: ranges::actions::reverse(baseContract->stateVariables())) | ||
| if (stateVariable->referenceLocation() == VariableDeclaration::Location::Unspecified) | ||
| for (ContractDefinition const* baseContract: _contract.annotation().linearizedBaseContracts) |
There was a problem hiding this comment.
I realized that linearizedBaseContracts is in order of the most-derived to most-base.
The last storage variable of the most-derived is the one which is closer to the end of storage.
There was a problem hiding this comment.
I think we should use the storage layout class for this (the one that calculates offsets). It's too easy to make this mistake. And the assumption that the order of definitions will match the order in storage is true only for now. When we finally introduce the full syntax for storage layouts, it will be possible for these two to be unrelated.
Though that's probably better done as a separate refactor. We need this fix for the upcoming release.
263706a to
842b794
Compare
|
This should be rebased on the fix PR. |
05b8cf0 to
b69dd6f
Compare
b69dd6f to
105f689
Compare
105f689 to
deb1c32
Compare
| // ---- | ||
| // Warning 3495: (11-35): This contract is very close to the end of storage. This limits its future upgradability. | ||
| // Warning 3495: (50-74): This contract is very close to the end of storage. This limits its future upgradability. | ||
| // Warning 3495: (89-109): This contract is very close to the end of storage. This limits its future upgradability. |
There was a problem hiding this comment.
I don't quite understand what is going on in this example. Why don't you get the secondary note about the last state variable here?
There was a problem hiding this comment.
And why are you rewriting this test? Was there a problem with it? Shouldn't this be a new test rather than rewriting an existing one?
There was a problem hiding this comment.
Syntax tests do not print secondary notes. This is usually what we want because they are very verbose. This does mean that we need a command-line test if we want to test them. Maybe we should add a new test setting (off by default) that forces them to show up when we do want them?
As for a new test, I think it's fine either way. I'd probably lean towards having a separate case for this as well, but it's also just a minor variation so seems acceptable to me to have one test covering both.
There was a problem hiding this comment.
I just rewrote it to cover these similar variations altogether as cameel mentioned.
deb1c32 to
ed1686c
Compare
ed1686c to
6c92d0b
Compare
Fix #16681.
Fix #16678.
Fix #16784.