This write-up looks fine to me. I mostly wanna push you in a simpler direction because I think the core of this is quite valuable for SwiftSyntax to have as you note. And it’s better we leave off the complicated bits and bobs if we can’t properly implement them.
Some things to bear in mind: Because you won’t be performing full qualified lookup here I think it’s important out of the gate that this library come with a qualifier like “lexical qualified lookup” to distinguish it from the operation you’d need to perform if you were writing something like a compiler or a full-project refactoring pass in an IDE.
We need a symbol table scoped to the nominal type
Circlethat aggregates members from all of the above sources in the correct precedence order.
You don’t actually! And to save yourself quite a bit of complexity I would actually shy away from using this as the foundation of your library. You “just” need a bit of name resolution and the ability to traverse the members of a given declaration. Adding a symbol table behind that amortizes the cost of repeated lookups and does sit underneath something like direct member lookup in a proper compiler but here I think a stateless implementation as a first pass is more desirable.
in the correct precedence order.
You don’t have to worry about ordering the results, or pruning them for that matter. It should be up to the caller to filter for access control, availability, generic constraints, etc. and sorting the output.
qualifiedLookup(_:on:in:)
I think the on parameter is superfluous given that you’re intending to use the syntax node you issue qualifiedLookup(_:on:in:) as the root of the search. I’d get rid of it.
QualifiedLookupResult
Which case do lookups rooted at generic parameters fall under? Is it fair to say that a witness satisfied by a generic parameter’s bounding protocols or superclass is a “member” of that type?
a complete name resolution path for Swift source code
complete, compiler-independent name resolution stack.
This is not quite right. You will get limited, lexical, file-scoped qualified name resolution out of this library. Which is totally fine! That’s a very useful facility to have.
Extensions with where clauses
I would say don’t worry about this. You will not have the ability to resolve any of the bounds involved. It should be up to a client that can resolve those bounds to do this filtering themselves. Just return the member in context as you have here.
Protocol inheritance chains.
Don’t worry about precedence. Clients can deal with shadowing and inheritance problems themselves.
Access control.
Don’t worry about filtering for access control. Access modifiers require semantic analysis to fully compute as well as a more well-fleshed-out generic scope implementation that SwiftSyntax doesn’t have. This is another “leave it to clients” thing.