Skip to content

fix(scip): recognise scip-dotnet (+N) overloads and drop the marker from names - #1740

Merged
Shashankss1205 merged 4 commits into
CodeGraphContext:mainfrom
PhysShell:fix/scip-dotnet-overloads
Oct 15, 2026
Merged

Shashankss1205 merged 4 commits into
CodeGraphContext:mainfrom
PhysShell:fix/scip-dotnet-overloads

Conversation

@PhysShell

Copy link
Copy Markdown
Contributor

Summary

scip-dotnet disambiguates C# method overloads as Type#M()., Type#M(+1)., Type#M(+2). and currently reports SymbolInformation.kind = 0 for them.

ScipIndexParser only recognized the (). suffix in its kind-0 fallback, so overloads after the first were dropped as function/method definitions. _name_from_symbol also kept the (+N) marker, producing names such as M(+1).

This change:

  • recognizes both (). and (+N). as callable SCIP symbols in the existing kind-0 fallback;
  • strips the (+N) overload marker during name normalization;
  • keeps parameter descriptors such as M(+1).(x) from being treated as callable definitions;
  • leaves the C++ zero-kind inference unchanged.

Tests

  • Added regression coverage using SCIP occurrences copied from real scip-dotnet output.
  • Regression before fix: 2 failed.
  • Regression after fix: 2 passed.
  • pytest tests/unit/tools -k scip: 28 passed.
  • Full fast suite: baseline 1608 passed / 8 skipped / 0 failed; patched 1610 passed / 8 skipped / 0 failed.
  • ruff check: no new violations.

PhysShell and others added 2 commits September 27, 2026 17:39
scip-dotnet names method overloads Type#M()., Type#M(+1)., Type#M(+2).
and reports kind 0 for all of them. ScipIndexParser keeps only the
first overload as a definition and names the rest, and calls to them,
M(+1) / M(+2).

Occurrences are copied from real scip-dotnet output over a
three-overload fixture.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
…rom names

scip-dotnet disambiguates method overloads as Type#M(+N). and reports
kind 0. The kind-0 fallback matched only the '().' suffix, so every
overload but the first was dropped as a definition. _name_from_symbol
stripped '()' but not '(+N)', so calls to those overloads were named
'M(+1)'.

A callable descriptor is now '().' or '(+N).'. Parameter descriptors
such as 'M(+1).(x)' are unaffected. The C++ zero-kind inference is
unchanged.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
@vercel

vercel Bot commented Sep 27, 2026

Copy link
Copy Markdown

@PhysShell is attempting to deploy a commit to the shashankss1205's projects Team on Vercel.

A member of the Team first needs to authorize it.

…erload

With (+N) overloads recognised, a C# file holds two `M` nodes. The SCIP
nodes arrive with args == [] (scip-dotnet leaves display_name empty), and
C# call records carry no arguments, so the Tree-sitter resolver resolves
neither `M()` nor `M(1)`. Only the SCIP file-level edges remain.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Hfh5zciucKoUGUdKjq3GwV
- The SCIP pipeline matches a SCIP function to its Tree-sitter twin by
  (name, line) instead of name alone, and fills empty `args` from it.
- The C# Tree-sitter parser records a call's arguments instead of a
  hard-coded empty list.

The existing arity check can then tell M() from M(int). Both calls
resolve Caller -> M to the matching overload again.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Hfh5zciucKoUGUdKjq3GwV

@Shashankss1205 Shashankss1205 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SCIP dotnet (+N) overload descriptors and line-specific C# augmentation fixes pass targeted tests; require real .NET fixture and CI.

@Shashankss1205
Shashankss1205 merged commit 80f485c into CodeGraphContext:main Oct 15, 2026
1 check failed
@github-project-automation github-project-automation Bot moved this from Backlog tasks to Done in CGC Progress Board Oct 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants