Code Relationship Graph in SourceKit-LSP

Development GSoC
1

Synopsis

This project aims to implement a feature in SourceKit-LSP that generates an interactive graph showing relationships between selected variables, classes, and references in Swift code. This will help developers understand code structure and navigate dependencies more efficiently.

Benefits to the Community

  • Improved Code Understanding – Clear visualization of code relationships.
  • Enhanced Debugging – Easier navigation through complex codebases.
  • Cross-Editor Support – Works with any editor supporting SourceKit-LSP.

Deliverables

Core

  • Graph generation using Graphviz or D3.js.
  • Custom LSP command (e.g., showHierarchy) to trigger graph creation.
  • Integration with SourceKit-LSP and VS Code extension.
  • Handle inheritance, composition, and references.

Optional

  • Interactive graph (expand/collapse nodes).
  • Clickable nodes for direct navigation.

Technical Approach

  1. Extract Relationships – Use SwiftSyntax to parse the AST and identify relationships.
  2. Graph Generation – Create nodes for variables, classes, and methods with edges representing relationships.
  3. LSP Command – Register a new LSP command to trigger graph generation.
  4. Editor Integration – Open the graph in a side panel in VS Code.
  5. Testing – Ensure accuracy, performance, and error handling.

Timeline

Phase Duration Goal
Community Bonding 2 weeks Setup environment, connect with mentors
Phase 1 3 weeks Relationship extraction
Phase 2 2 weeks Graph generation
Phase 3 2 weeks LSP command + editor integration
Final Phase 2 weeks Testing, performance, and documentation

Biographical Info

  • Skills: Swift, C, C++, Python, JavaScript
  • Experience:
    • Built a low-level x86 OS
    • Strong in computer architecture and AST parsing
    • First Time participating in GSOC

Why Me?

My experience in systems programming, computer architecture, and AST parsing makes me a strong candidate. I have led multiple software projects and am confident in delivering a high-quality solution that benefits the Swift community.

2 Likes
2

Hi @NikhilBisht2,
I'll just chime in process wise -- the forums posts are not applications to the program. You should use these threads to talk with your potential mentors. You will have to submit a proposal on the summer of code website to be considered for the program. Please refer to the timeline and contributor guide. Please familiarize yourself with those in depth, and use the time now to talk to your potential mentors rather than just post a proposal draft.

Here's also a few hints about how and when to apply: Advice for People Applying for GSoC  |  Google Summer of Code  |  Google for Developers

3

Hi @ktoso ,
The GSOC 25 contributor application period will start from 24 March , before that we're supposed to discuss our plans with potential mentors . My post was meant to discuss my idea . I probably should introduced myself first , I'm sorry about that .

4

Hi there, yeah that's totally fine!

I was just trying to point at the fact that since this is a custom project, you'd need to focus on finding a mentor for it.

Looking at the existing projects list it seems maybe @matthewbastien could comment if they'd consider this new project idea over existing ones (like the Swiftly integration etc), but it seems the Swiftly one may be rather important to pull off hm.

I would suggest focusing on finding a mentor for a custom project idea and checking in if such project idea would be considered by some potential mentor, before making more efforts into polishing up a specific proposal. Hope this helps!

5

Thanks @ktoso , I will try to reach out to other mentors . But first I would love to know your opinion on this project too before I start to look for potential mentors , do you think this project have potential , please be blunt.

6

I'm a little worried that it is a bit not specific enough; We'd have to get an outline of exact milestones and what kinds of relationships we'd draw. I'm not sure the d3 approach would be viable.

For example if we had such thing, maybe docc could also use it to show relationships in docs, as well as in IDEs as this proposes? In other words, a little worried this could be a bit unclear where to draw the line and at the same time it feels less bang-for-buck than the other VSCode proposals hmmm...

But I'm just taking care of process, it's up to mentors of the respective domain expertise to say if this is maybe indeed of great value or not.

Maybe @adam-fowler can share some initial impression as well, though he probably may not have the capacity to mentor such project.

7

Thanks , I'll reach @adam-fowler and @matthewbastien and get their perspective too . If it doesn't work out I'll ideate some more or stick to the projects listed.

8

Hi,

As @ktoso says you need to be more clear what those relationships are.

VSCode already has a number of UIs for displaying relationships ( although not in a graph visualisation). You can get a list of references of a type, you can get callers of a function, display type hierarchies. So many of these already have implementations in LSP.

Given the above, is there any reason for a new LSP feature. If there is, what is the expected output of a showHierarchy request. Is this a custom feature that isn't in the LSP spec? Is there anything in the upcoming 3.18 LSP specification that could be used?

I don't have too many worries about rendering D3.js output in a VSCode window, given VSCode is able to display web pages.

As @ktoso says though. I have backed away from VS Code extension development and the Apple team (including @award999 , @plemarquand @matthewbastien ) are almost exclusively responsible for development. So I am not in a position to mentor this project.

@ahoppen the main developer on SourceKit-LSP might have some thoughts about this as well.

1 Like