[GSoC 2026] Proposal draft review: DocC Language Features in SourceKit-LSP

Development GSoC
1

Hey @matthewbastien @snprajwal

I'm a Software Engineer (iOS) at Vodafone Egypt with a strong interest in Swift tooling and the Language Server Protocol. I'd love to work on the DocC Language Features in SourceKit-LSP project this GSoC.

I've been contributing to the Swift open-source ecosystem — I helped land PR #2404 in SourceKit-LSP (preventing jump-to-definition on literal values), which gave me a solid understanding of how definition requests flow through the language service layer. I also implemented the "Convert to Ternary Expression" refactoring action in swift-syntax (PR #3252), which deepened my familiarity with SyntaxVisitor and SyntaxRewriter.

I've drafted my proposal and would really appreciate your feedback before the submission deadline
The Proposal: Proposal Link

A few things I'd especially love your input on:

  1. For go-to-definition, I'm planning to leverage DocCReferenceResolutionService rather than a workspace-wide symbol search, so SourceKit-LSP handles resolution with full documentation context. Does that align with how you'd expect this to be wired up?

  2. For diagnostics, I'm aiming for inline red underlines published via textDocument/publishDiagnostics rather than just suppressing broken links in the preview. Is there a preferred place in DocumentationLanguageService to hook into this?

  3. For preview navigation, I'm keeping all resolution logic server-side (in DocumentationLanguageService) with only a thin webview shim on the VS Code extension side — so other editors benefit too. Does that match your vision for the feature?

Happy to discuss further or adjust the scope. Thanks for your time!

— Ahmad Ayman Mansour (@ahmad)

1 Like
2

Hi @ahmad,

Thank you for your interest in this project. @matthewbastien and I reviewed your proposal, and we feel that while the solutions for the different parts of the problem statement are appropriate at a high level, they do not present any concrete details about how this will be implemented, and what parts of the pipeline they will be interacting with (SourceKit, DocC, VSCode extension). This is a good starting point, but it is too brief, and each of the proposed solutions can be expanded upon in more detail. It would also be great if you could demonstrate that you understand the different parts of the LSP pipeline, and what challenges might be encountered while attempting to implement these solutions.

We would also like to emphasise that while using the support of AI is acceptable, it is required that you understand what is generated by the model, and that you thoroughly review and vet the output before including it. For instance, in the section “Warnings for Broken Symbol References”, you summarise mentor feedback that was not addressed to your proposal, and do not explain why it’s relevant to your implementation. It reads very much like an AI summary that was copied into the proposal. It is expected that the proposal is written by yourself, in your own voice. Please refer the Swift org AI usage policy for more details regarding this.

1 Like