feat: add method_id member to interface functions by johnnyonline · Pull Request #4903 · vyperlang/vyper

johnnyonline · 2026-04-06T18:34:27Z

What I did

Implemented VIP #2098 - added a method_id_of builtin function, allowing direct access to the 4-byte function selector via method_id_of(Interface.function).

How I did it

InterfaceT.get_member_in_expr exposes functions in expression context (gated from annotation path to prevent use as type)
Added method_id_of builtin in builtins/functions.py with build_IR for legacy codegen
Added venom handler in codegen_venom/builtins/misc.py
Optional n_optional_args kwarg to specify how many default args to include in the signature (defaults to 0, positional-only)

How to verify it

pytest tests/functional/codegen/test_interface_method_id.py tests/functional/syntax/test_interface_method_id.py -x -v

Commit message

feat: add method_id_of builtin function

Description for the changelog

Added method_id_of builtin function, enabling method_id_of(ERC20.transfer) syntax to retrieve the 4-byte function selector as bytes4.

Cute Animal Picture

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b5dcdff3b0

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-04-06T18:42:31Z

+        if attr in self.functions:
+            return TYPE_T(self.functions[attr])


Reject interface function types in annotations

Exposing interface functions from get_type_member makes IFoo.transfer parse as a concrete annotation type via type_from_annotation(...), even though ContractFunctionT is not a valid ABI/storage type. As a result, declarations such as x: public(IFoo.transfer) can get past type parsing and then fail later when ABI/getter generation needs to_abi_arg (function types do not implement abi_type), producing an internal compiler failure instead of a user-facing type error. This member should be gated to expression use (...method_id) and not accepted as a general annotation type.

Useful? React with 👍 / 👎.

charles-cooper

i think maybe it makes sense for the evaluation to happen during constant folding? cc @Sporarum

Sporarum · 2026-04-08T14:40:49Z

As for constant folding, I guess it technically is a compile-time constant, but I would not expect constant folding to be doing that job

We could instead move the computation to something like ContractFunctionT.encoded_method_id
(encoded because we apparently need to modify the value we got from method_ids: value = method_id << 224)

Also see my comments on the VIP: #2098 (comment)

Sporarum · 2026-04-08T14:19:05Z

                return VyperValue.from_stack_op(IRLiteral(value), typ)

-        # Case 2: Address properties
+        # Case 1b: Interface.function.method_id (e.g. ERC20.transfer.method_id)


Case 1 should be modified to Case 1a then

Fixed here 532e685

…od_id

johnnyonline · 2026-04-08T14:59:38Z

We could instead move the computation to something like ContractFunctionT.encoded_method_id
(encoded because we apparently need to modify the value we got from method_ids: value = method_id << 224)

Done here 9f51422

Also see my comments on the VIP: #2098 (comment)

Re default args, current implementation uses the full signature (all args). Happy to change if a different behavior is preferred

Re naming (method_id vs __method_id__), FWIW, the reasoning in @Sporarum's comment makes sense to me

charles-cooper · 2026-04-12T17:16:06Z

cf. #2098 (comment) on functions with default args

…only)

johnnyonline · 2026-04-12T23:26:21Z

First commit defaulted n_args to all args (full signature) but realized that probably not alligns with the spec so second commit renames to n_optional_args and defaults to 0

This way method_id_of(ERC20.transfer) just works for the common case and for functions with defaults like def foo(x: uint256 = 0), method_id_of(IFoo.foo) --> foo() and method_id_of(IFoo.foo, n_optional_args=1) --> foo(uint256)

If n_optional_args is too verbose i will happily shorten it back to n_args. Mostly went with this so we're fully clear on the intent (tbh personally i also prefer more explicit too)

charles-cooper · 2026-05-04T10:09:28Z

do we want to handle things like n_args=-2?

charles-cooper · 2026-05-15T07:20:46Z

do we want to handle things like n_args=-2?

ok i think we can actually handle this as a follow up. the PR looks good to me, @Sporarum do you have any more comments?

Sporarum

@charles-cooper I think we should not default to 0, and instead force the user to specify the count if there are kwargs: #2098 (comment)

And a couple small comments:

Sporarum · 2026-05-18T07:39:28Z

+    builtin = MethodIDOf()
+    selector = builtin._compute_method_id(node)


Suggested change

builtin = MethodIDOf()

selector = builtin._compute_method_id(node)

selector = MethodIDOf()._compute_method_id(node)

Sporarum · 2026-05-18T07:43:58Z

@@ -443,6 +443,10 @@ def infer_kwarg_types(self, node):
    # dispatch into get_type_member if it's dereferenced, ex.
    # MyFlag.FOO
    def get_member(self, key, node):


Why is this change required ?

Sporarum · 2026-05-18T07:44:34Z

        # get an event, struct or flag from this interface
        return TYPE_T(self._helper.get_member(attr, node))

+    def get_member_in_expr(self, attr, node):


I think this function name is confusing, I don't see what it semantically means

Sporarum · 2026-05-18T07:50:00Z

+        for kw in node.keywords:
+            if kw.arg == "n_optional_args":


This seems a bit convoluted, wouldn't node.keywords.get("n_optional_args", 0) or something like it work ?

How do the other built-ins deal with kwargs ?

Sporarum · 2026-05-18T07:52:52Z

+        # default: 0 optional args (positional only)
+        return 0
+
+    def _compute_method_id(self, node):


Is this logic a duplicate ?
It seems like we would already have something to compute that

feat: add method_id member to interface functions

b5dcdff

chatgpt-codex-connector Bot reviewed Apr 6, 2026

View reviewed changes

fix: gate interface function access to expression context only

4444ef6

charles-cooper reviewed Apr 8, 2026

View reviewed changes

charles-cooper requested a review from Sporarum April 8, 2026 09:23

Sporarum reviewed Apr 8, 2026

View reviewed changes

johnnyonline added 2 commits April 8, 2026 11:50

chore: rename Case 1 to Case 1a in venom codegen

532e685

refactor: move method_id encoding into ContractFunctionT.encoded_meth…

9f51422

…od_id

Sporarum mentioned this pull request Apr 9, 2026

VIP: add method_id member to interface functions #2098

Open

johnnyonline added 2 commits April 12, 2026 19:52

refactor: replace .method_id attribute with method_id_of builtin

ea31b8d

refactor: rename n_args to n_optional_args, default to 0 (positional-…

c5759fe

…only)

charles-cooper approved these changes May 15, 2026

View reviewed changes

Sporarum requested changes May 18, 2026

View reviewed changes

		if attr in self.functions:
		return TYPE_T(self.functions[attr])

		builtin = MethodIDOf()
		selector = builtin._compute_method_id(node)

	builtin = MethodIDOf()
	selector = builtin._compute_method_id(node)
	selector = MethodIDOf()._compute_method_id(node)

Uh oh!

Conversation

johnnyonline commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What I did

How I did it

How to verify it

Commit message

Description for the changelog

Cute Animal Picture

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Apr 6, 2026

Choose a reason for hiding this comment

Uh oh!

charles-cooper left a comment

Choose a reason for hiding this comment

Uh oh!

Sporarum commented Apr 8, 2026

Uh oh!

Sporarum Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

johnnyonline Apr 8, 2026

Choose a reason for hiding this comment

Uh oh!

johnnyonline commented Apr 8, 2026

Uh oh!

charles-cooper commented Apr 12, 2026

Uh oh!

johnnyonline commented Apr 12, 2026

Uh oh!

charles-cooper commented May 4, 2026

Uh oh!

charles-cooper commented May 15, 2026

Uh oh!

Sporarum left a comment

Choose a reason for hiding this comment

Uh oh!

Sporarum May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Sporarum May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Sporarum May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Sporarum May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Sporarum May 18, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

johnnyonline commented Apr 6, 2026 •

edited

Loading