My name is Rohit Kumar, and I’m a computer science student deeply interested in compilers, programming language tooling, and static analysis. Recently I’ve been exploring the Swift compiler architecture and the SwiftSyntax ecosystem, and I’m planning to apply for Google Summer of Code 2026 with the Swift organization.
I’m particularly interested in the project “Qualified Name Lookup for swift-syntax.”
From my understanding, the goal of this project is to implement qualified name lookup semantics for SwiftSyntax so that tools can resolve references such as A.f to the correct declaration across types, extensions, protocols, and inheritance hierarchies.
One idea I’ve been exploring is whether a lazy, query-driven architecture could work well for this problem. Instead of building a full global symbol table eagerly, the lookup system could resolve symbols on-demand and cache results as needed. Conceptually, this could be inspired by the request-evaluator architecture used in the Swift compiler.
A possible direction might involve:
• Using the existing SwiftLexicalLookup library to identify the syntactic scope of the base type
• Building a lightweight representation of type relationships (types, extensions, and protocol conformances)
• Resolving members lazily only when a qualified lookup targets that scope
• Providing clean APIs so that source tools can efficiently query the resolved symbols
However, I’m still exploring the design space and would really appreciate feedback from mentors on whether a lazy evaluation approach aligns with the goals of this project.
If there are recommended starter issues or particular parts of the SwiftSyntax codebase that would be good to study first, I would be very grateful for the guidance.
Thank you for pointing me to that thread! Reading through Doug’s and Filip's discussion was incredibly insightful and completely clarified the boundaries of this project for me.
It is clear that the goal is to build a robust, pure-syntax facility without dragging in the heavy machinery of the compiler's semantic analysis. To align exactly with Doug's vision in that thread, I am structuring my approach around a stateless API model rather than a custom request-evaluator.
My core approach is now focused on the following pillars:
1. The Stateless lookupForMembers API
I will focus entirely on implementing APIs resembling lookupForMembers(in:name:).
The API will remain decoupled from the compiler's request-evaluator, leaving that integration to swiftc itself. It will serve purely as a syntactic utility for tools throwing swift-syntax trees at it.
2. Traversal & Directives
I plan to build the core member extraction using standard SwiftSyntax visitors.
To handle #if compiler directives gracefully without overcomplicating the logic, I will utilize ActiveSyntaxAnyVisitor as Doug suggested.
3. Strict Syntactic Scoping
Based on the thread, I will explicitly define the following as out of scope for the core implementation, as they require semantic analysis or external resolution:
Associated types, generic parameters, and where clauses.
Expanding attached macros.
C/C++ interop declarations.
Full cross-module resolution (focusing instead on providing the API hooks for tools to supply module data).
4. Compiler-Free Testing Harness
I will implement a robust testing strategy entirely within the swift-syntax repository.
This will rely on annotated Swift source code (similar to the SwiftLexicalLookup flow) to verify lookup paths deterministically without invoking the compiler.
Does this strictly API-driven, stateless direction perfectly align with the current expectations for the GSoC timeframe?
I am currently prototyping a small ActiveSyntaxAnyVisitor to extract direct members and extensions from a single file to get comfortable with the immediate constraints.
Thanks again for all the pointers and for sharing those threads. They were incredibly helpful in scoping the project correctly and avoiding over-engineering.
Based on our discussions and Doug’s insights about keeping the API stateless and purely syntactic, I have put together my draft proposal for GSoC 2026.
Strict syntactic boundaries (explicitly leaving access control filtering and generic constraints to the caller).
Utilizing ActiveSyntaxAnyVisitor for handling directives gracefully.
A compiler-free, marker-based testing strategy.
I would be really grateful if you could take a quick look when you have some time. I am particularly interested in knowing if the timeline looks realistic and if my "Out of Scope" section perfectly aligns with the team's expectations.
I am more than happy to make adjustments based on your feedback before the final submission.