fix: disambiguate library functions vs native properties in member access #108
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for your contribution to the Solidity compiler! A team member will follow up shortly. If you haven't read our contributing guidelines and our review checklist before, please do it now, this makes the reviewing process and accepting your contribution smoother. If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the #solidity-dev channel on Matrix. |
yorhodes
force-pushed
the
fix/member-access-disambiguation
branch
2 times, most recently
from
8c5fea7 to
0b189a4
Compare
…cess When both a native property (e.g., address.isContract) and a library function with the same name are available via 'using for', disambiguate based on call syntax: - With parentheses: prefer library function (e.g., a.isContract()) - Without parentheses: prefer native property (e.g., a.isContract) This allows OpenZeppelin's Address.isContract() library function to work alongside Tron's native address.isContract property without conflict. The fix mirrors the identifier resolution pattern in visit(Identifier) where VariableDeclarations are preferred without parentheses (lines 3693-3745 in TypeChecker.cpp). Fixes the error: 'Member "isContract" not unique after argument-dependent lookup in address' when using OpenZeppelin contracts on Tron.
yorhodes
force-pushed
the
fix/member-access-disambiguation
branch
from
0b189a4 to
6847d0c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
This PR fixes an issue where using OpenZeppelin's
Address.isContract()library function on Tron causes a compilation error:This happens because Tron's native
address.isContractproperty (added in TIP-44) conflicts with library functions attached viausing Address for address;.Problem
When code uses:
The compiler finds two members named
isContract:address.isContract(boolean, uses ISCONTRACT opcode)Address.isContract(address)attached viausing forSolution
Disambiguate based on call syntax:
a.isContract(): prefer library functionWithout parentheses (
a.isContract) remains unchanged and will still error with "not unique" when both a native property and library function exist.Changes
libsolidity/analysis/TypeChecker.cpp: Added disambiguation logic to filter out non-functions when called with parenthesestest/libsolidity/syntaxTests/memberLookup/:library_function_vs_native_property_with_parens.sol- verifies library function is used with()native_isContract_property.sol- verifies native property still works standaloneBehavior After Fix
addr.isContract()addr.isContract(nousing for)addr.isContract(withusing for)Motivation
This enables Hyperlane and other protocols using OpenZeppelin contracts to deploy on Tron without modification.