feat[lang]: add abstract methods by Sporarum · Pull Request #4875 · vyperlang/vyper

Sporarum · 2026-03-05T16:11:31Z

What I did

Implement "initializes-based proposal v2" of #4730
With the change that calling an abstract method requires usesing its module.
This forces the abstract module to be initializes, and hence overridden, somewhere.

Note that this PR does not add docs for this feature !
It does not either change venom in any way !
(not even assertions to make sure it crashes on abstract methods)

How I did it

How to verify it

Commit message

this commit add abstract methods to vyper and a way to override them. it
implements the abstract methods VIP as defined in "initializes-based
proposal v2" with the one change that using an abstract method requires
uses-ing its module. calls to abstract functions are treated as if they
were calls to their override. this requires decoupling the call graph
from the import graph (and any method dealing with either). this commit
also heavily tests the new feature, and hopefully all edge cases are
covered. some refactoring was performed to facilitate the
implementation: to make namespaces easier to reason about and
manipulate, Namespace is refactored to be immutable and uses instead a
contextvar to be passed implicitly and updated. to make analyzing nodes
easier, NodeAccumulator is added, it works similarly to
VyperNodeVisitorBase but is designed with immutability in mind, as such
its methods return an accumulator value instead of mutating state. to
make reasoning about typing easier, is_supertype_of, is_subtype_of and
is_equivalent_to methods are added to vyper types. the original,
compare_type, was sometimes used to check both equivalence and
subtyping. when all usages are disambiguated, it should be removed.

Description for the changelog

(Not sure what the format is for these, let me know if this can be improved)

Add @abstract and @override decorators to make modules overridable

Cute Animal Picture

Seems to have been always empty anyways

The result from the original was never used, and should not have been anyways, as it only extracts a single terminating node, when there can be multiple

It seems correct, but I am not familiar enough with these complicated classes to be sure there are no mistakes

…space) pair of classes

…e unneeded later

…e into a ContextVar

…order Now functions in CompilerData only call methods before them, so you can have a clearer idea of what has and hasn't been executed Note: This does not guarantee every method before the one you are on will have been called!

charles-cooper · 2026-03-20T13:58:05Z

vyper/semantics/analysis/local.py

+
+        if self.func.return_type and not _is_terminated:
+            raise FunctionDeclarationException(
+                f"Missing return statement in function '{self.fn_node.name}'", self.fn_node


now i see why it was originally find_terminating_node, i guess the intent was to have a hint pointing to exactly which branch was not terminated

Should I refactor it to do that ? (Or add a TODO)

The issue is that it's always possible to add a return at the very end of a block, so there's not really a location to point to

charles-cooper · 2026-03-20T14:00:10Z

vyper/semantics/analysis/local.py

+        if varaccess is not None:
+            self.loop_variables.append(varaccess)
        try:
            yield
        finally:
-            self.loop_variables.pop()
-
-    def visit(self, node):
-        super().visit(node)
+            if varaccess is not None:
+                self.loop_variables.pop()


at this point i would rewrite the entire block so that the branching is clear

Suggested change

if varaccess is not None:

self.loop_variables.append(varaccess)

try:

yield

finally:

self.loop_variables.pop()

def visit(self, node):

super().visit(node)

if varaccess is not None:

self.loop_variables.pop()

if varaccess is None:

yield

return # if this is not possible then use an else branch

self.loop_variables.append(varaccess)

try:

yield

finally:

self.loop_variables.pop()

charles-cooper · 2026-03-20T14:01:23Z

vyper/semantics/analysis/local.py

+                )
+            is_abstract = func._metadata["func_type"].is_abstract
+
+            if is_abstract:


do we visit the bodies of abstract functions?

Not anymore, see cf802b8

vyper/semantics/analysis/local.py

charles-cooper · 2026-03-20T14:02:37Z

vyper/semantics/analysis/local.py

+                    if root_module_info is not None:
+                        self.func.mark_used_module(root_module_info)
+
+                    # Note: We don't check what the override touches, as this would severely hurt


we can't just not validate it lol, in that case the overriding module is responsible for declaring uses!

The concrete methods in an abstract module are validated !

What we don't do is look at the override of abstract methods (who live in another module), and use their body to add requirements to the abstract module

See test_overriding_module_can_initialize_state for an example of what would happen otherwise:

# abstract module: # if the following was needed, it would severely limit the usefulness of the feature # uses: stateful @abstract def process() -> uint256: ... # override module: import stateful import b_module initializes: stateful initializes: b_module @override(b_module) def process() -> uint256: stateful.increment() return stateful.get_counter()

charles-cooper · 2026-03-20T14:03:56Z