Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Private functions can't have duplicate function selectors #1687

Closed
smarx opened this issue Nov 9, 2019 · 0 comments · Fixed by #1800
Closed

Private functions can't have duplicate function selectors #1687

smarx opened this issue Nov 9, 2019 · 0 comments · Fixed by #1800
Labels
bug Bug that shouldn't change language semantics when fixed.

Comments

@smarx
Copy link
Contributor

smarx commented Nov 9, 2019

This is an unnecessary constraint. Label names can be made unique.

@private
@constant
def gfah(): pass

@private
@constant
def eexo(): pass

# error: Label with name priv_236395036 already exists!
@fubuloubu fubuloubu added the bug Bug that shouldn't change language semantics when fixed. label Nov 10, 2019
This was referenced Jan 3, 2020
Closed
Merged
charles-cooper added a commit to charles-cooper/vyper that referenced this issue Sep 1, 2023
@charles-cooper
feat: relax restrictions on internal function signatures
bb017fd 
relax the restriction on unique "method ids" for internal methods. the
check used to be there to avoid collisions between external method ids
and internal "method ids" because the calling convention for internal
functions used to involve the method id as part of the signature, but
that is no longer the case. so we can safely allow collision between
internal "method ids" and external method ids.

cf. issue vyperlang#1687 which was resolved in in 9e8c661.

chainsec june 2023 review 5.22
@charles-cooper charles-cooper mentioned this issue Sep 1, 2023
Merged
charles-cooper added a commit that referenced this issue Sep 1, 2023
@charles-cooper @tserg @trocher
feat: relax restrictions on internal function signatures (#3573)
a19cdea 
relax the restriction on unique "method ids" for internal methods. the
check used to be there to avoid collisions between external method ids
and internal "method ids" because the calling convention for internal
functions used to involve the method id as part of the signature, but
that is no longer the case. so we can safely allow collision between
internal "method ids" and external method ids.

cf. issue #1687 which was resolved in in 9e8c661.

chainsec june 2023 review 5.22
---------

Co-authored-by: tserg <[email protected]>
Co-authored-by: trocher <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Bug that shouldn't change language semantics when fixed.
Projects
None yet
Milestone
No milestone
2 participants
@smarx @fubuloubu