[GSoC 2026] Demonstration and Implementation Approach: DocC Language Features in SourceKit-LSP

Hey @matthewbastien @snprajwal

I am a Computer Science student from India and I would love to work on this project!

I have experience building projects in JavaScript (including a Chrome extension and a React application), and I’m currently working with TypeScript as a part of this project. I’ve also been working with Swift recently and have contributed to swift-syntax and SourceKit-LSP.

(#3249, #3231, #2496)

I implemented the Go-to-Definition along with diagnostics for missing or broken links.

Demo Video: Go-To-Definition-Demo
GitHub Fork : https://github.com/Padmashree06/vscode-swift/tree/doc-go-to-definition

My approach :

Before Doc Preview:

  1. Extract the symbol links along with their symbol names from the currently open document.

  2. Search the workspace asynchronously for the symbol definition using vscode.executeWorkspaceSymbolProvider command .

  3. If found we store the SymbolName along with its file URI and range in the SymbolUriMap.

When the user clicks on the symbol link in Doc Preview:

  1. Event handler that retrieves the symbol name from the Webview URI.

  2. Check SymbolUriMap for the symbol.

  3. If found, retrieve its stored file URI and range, open the file and navigate to the definition range.

  4. If the symbol is not found, display an informational message stating “Symbol not found.”

Question:

The project goals mentioned in the project description,

  • Clicking on links within live preview should take the user to the symbol.

  • Go to definition for symbols that appear in DocC documentation.

Don’t they compliment each other?

My understanding is that, when the user clicks on the symbol link in DocC preview it should take the user to the symbol definition.

For go to definition, even if the symbol is not written as a link it must take the user to the symbol definition.

Is this interpretation correct?

To improve this further:

  1. When a user clicks a broken link, along with showing an alert message, the editor could also navigate to the location in the document where the broken link is written.

  2. I’m also thinking of integrating it with sourcekit LSP so that the broken links show diagnostics in the editor, such as red underlining and hover information indicating that the referenced symbol does not exist.

  3. For go-to-definition of all the symbols mentioned in the document, another idea is to automatically detect symbol names and convert them into clickable links so that the same navigation logic can be reused. If this is valid.

  4. For Syntax highlighting, I’m referring to the VS code documentation : https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide

    I would like to validate my approach and would like to know if there are any other features that you would expect!!!

2 Likes