Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature]: C#: interface dispatch stops at the interface when there is more than one implementer, and property access through an interface is not linked

Open
  • Is something wrong?
#3,800 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Goodkamalpandey is already working on this.

Since Oct 13, 2026.

  • #4396 by @Goodkamalpandey — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, python
Domain
devtools

Research direction

Start in the C# resolution layer (the tree-sitter csharp module and the interface-dispatch code path, which today only proceeds when exactly one implementer exists — same area as #3003). Build the graph over the single-file Conn.cs repro in the issue to confirm the current output: only references to IConnecter and calls to IConnecter.Read, with no dispatches_to and nothing for c.Count. Done means dispatches_to edges from IConnecter.Read to both Effect.Read and Property.Read, plus an edge for the interface-typed property read; extend the existing C# resolution tests for the single-implementer case.

Written by the indexing model from the issue text.

Description

enhancement
Problem or use case

Related to #3003. Once a call has reached an interface member, a walk only continues to the
implementation when the interface has exactly one implementer. With two or more, the graph
stops at the interface, which is where most interfaces in practice sit. Reading a property through
an interface-typed receiver produces no edge at all.

Repro, one file, Conn.cs:

namespace Demo
{
    public interface IConnecter { void Read(); int Count { get; } }

    public class Effect : IConnecter
    {
        public void Read() { }
        public int Count => 0;
    }

    public class Property : IConnecter
    {
        public void Read() { }
        public int Count => 1;
    }

    public class User
    {
        public void Go(IConnecter c)
        {
            c.Read();
            int n = c.Count;
        }
    }
}

Actual:

conn_demo_user_go --references--> conn_demo_iconnecter
conn_demo_user_go --calls-->      conn_demo_iconnecter_read

No dispatches_to from IConnecter.Read() to either implementation, and nothing for c.Count.

Proposed solution
  1. dispatches_to from an interface member to the same-named member of every implementing
    type (and subclasses of one), explicit implementations included, with confidence: INFERRED
    and perhaps a score that falls with the implementer count. #3003's reasoning ("guessing among
    several implementers would not" mirror the runtime) is right for a single call site, but for a
    static structural graph the question is "what can this call reach", and the answer is all of
    them. Stopping at the interface answers "nothing".
  2. A calls edge (or a distinct relation such as accesses) from a method to an interface
    property it reads or writes through an interface-typed receiver. Property getters are method
    calls, and in interface-heavy code they are a large share of the traffic across the seam.
    Limiting this to interface receivers would keep it from flooding the graph with every
    obj.Name read.
Alternatives considered

No response

Area

Graph building or querying

Additional context

in a Unity codebase whose editor assembly may only reach the runtime through interfaces,
the busiest seam interface has three implementers and much of the editor's traffic through it is
property reads (Ed.DataOwner, Ed.EditorLayouts). A local post-pass doing exactly (1) and (2)
added about 170 member-level dispatch edges and 190 property-access edges to a ~120-file graph,
and made editor-to-implementation paths two hops long.

Dominant language
Python
Stars
124k
Forks
11.9k
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Graphify-Labs/graphify

All issues in Graphify-Labs/graphify

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.