Avoid validation error when function parameter has internal function pointer #1038
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem:
The following function
https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/e49c574f71d402bbd5905175ec2205af02e87dda/contracts/governance/utils/VotesUpgradeable.sol#L259-L262 causes the Upgrades plugin to give a validation error: Variable
op
is an internal functionThis appears to be a false positive, since the internal function pointer comes from the same implementation code and is not kept in storage.
Background:
In #1032, we added validation errors for internal function pointers in storage variables.
This was done by using solidity-ast's
findAll
to look for all transitive nodes of typeVariableDeclaration
within aContractDefinition
.The goal was to check all direct variables of a contract, or all variables within structs. But the contract's functions' parameters can also have
VariableDeclaration
type (which may be function pointers), and these are also transitive children of the contract -- these should be ignored.Fix:
Instead of checking all transitive
VariableDeclaration
nodes from a contract, only check those from its direct variables or from its structs.Fixes #1037