Resolve reference-like requests from the index for unopened files#2713
Open
rintaro wants to merge 1 commit into
Open
Resolve reference-like requests from the index for unopened files#2713rintaro wants to merge 1 commit into
rintaro wants to merge 1 commit into
Conversation
9a9e272 to
b1e5917
Compare
Member
Author
|
@swift-ci Please test |
b1e5917 to
2129b74
Compare
`references`, `prepareCallHierarchy`, `implementation`, and `prepareTypeHierarchy` previously resolved the symbol at the requested position by asking the document's language service for cursor info, which requires the document to be open. As a result, these requests returned nothing when invoked on a position in a file the editor hadn't opened — the common case when Find References, Call Hierarchy, Jump to Implementations, or Type Hierarchy targets a definition in another file. Resolve the USR(s) at the requested position from the index when the document is not open, falling back from the language service. Occurrence locations are mapped to LSP positions using the file's on-disk contents (via the snapshot-or-disk line table), so no language service or sourcekitd document is needed. When the document is open we still prefer cursor info from the live buffer, which is more precise and also resolves local, non-indexed symbols. The shared resolution lives in a new `usrsOfSymbol(at:in:workspace:index:)` helper, and the resolved USRs are sorted and de-duplicated so results are deterministic. `prepareTypeHierarchy` no longer pre-filters cursor-info symbols by kind; the existing filter on the index symbol kind is authoritative and applies to both resolution paths. Add `CheckedIndex.symbolOccurrences(inFilePath:)`, which returns up-to-date occurrences carrying their locations, to support this lookup.
2129b74 to
638e7f9
Compare
Member
Author
|
@swift-ci Please test |
Member
Author
|
@swift-ci Please test Windows |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
textDocument/references,textDocument/prepareCallHierarchy,textDocument/implementation, andtextDocument/prepareTypeHierarchypreviously resolved the symbol at the requested position via the document's language service (symbolInfo), which requires the document to be open. Invoked on a position in a file the editor hadn't opened, they returned nothing.These requests now resolve the USR(s) at the requested position directly from the index when the document is not open. When the document is open we still prefer cursor info from the live buffer, which is more precise and also resolves local, non-indexed symbols. This matches the LSP model (on-disk contents are authoritative for a closed document). The shared resolution lives in a new
usrsOfSymbolhelper, and the resolved USRs are sorted and de-duplicated for deterministic results.prepareTypeHierarchyno longer pre-filters the cursor-info symbols by kind; the existing filter on the index symbol kind is authoritative and applies to both resolution paths.To support this,
CheckedIndexgainssymbolOccurrences(inFilePath:), returning up-to-date occurrences with their locations.