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
Problem
Go to implementation returns no target for a member accessed through
super(), even when ty has resolved the member to a parent class:Invoking go to implementation on
runinsuper().run()should navigate toBase.run.The lookup must distinguish the inherited member definition from the definition invoked by the resulting callable. For example, if
Base.runis an assignment to a callable object, navigation should select theBase.runassignment 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 resolvesuper(), so both Pyrefly and ty currently return no target.Possible approach
Extend attribute-definition resolution to understand bound
superreceivers by searching the owner's MRO after the pivot class. The current implementation deliberately skipsBoundSuper, 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
superlookup should not scan unrelated project files or search subclasses.Acceptance criteria
super()navigates to that parent method.super()member is a callable-valued assignment, navigation selects the member assignment rather than the callable object's__call__method.super()receivers return the deduplicated implementations resolved for their possible MROs without scanning unrelated project files.