Skip to content

Go-to implementation should be supported for members accessed through super() #4143

Description

@lerebear

Problem

Go to implementation returns no target for a member accessed through super(), even when ty has resolved the member to a parent class:

class Base:
    def run(self) -> int:
        return 1


class Child(Base):
    def call_parent(self) -> int:
        return super().run()

Invoking go to implementation on run in super().run() should navigate to Base.run.

The lookup must distinguish the inherited member definition from the definition invoked by the resulting callable. For example, if Base.run is an assignment to a callable object, navigation should select the Base.run assignment rather than the callable object's __call__ method.

This follows up on astral-sh/ruff#25410.

By contrast, basedpyright supports go to implementation through super(), including callable-valued member assignments; Pyrefly's child-implementation search does not resolve super(), so both Pyrefly and ty currently return no target.

Possible approach

Extend attribute-definition resolution to understand bound super receivers by searching the owner's MRO after the pivot class. The current implementation deliberately skips BoundSuper, while go to implementation depends on resolved attribute definitions to prepare its finder.

Once the exact member definitions are available, normalize overloads, property accessors, and stub mappings as usual. A resolved super lookup should not scan unrelated project files or search subclasses.

Acceptance criteria

  • Go to implementation on an ordinary parent method accessed through super() navigates to that parent method.
  • When a super() member is a callable-valued assignment, navigation selects the member assignment rather than the callable object's __call__ method.
  • Overloaded parent methods navigate to their concrete implementation when one exists.
  • Constrained or union-valued super() receivers return the deduplicated implementations resolved for their possible MROs without scanning unrelated project files.

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-designNeeds further design before implementationserverRelated to the LSP server

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions