Filter index entries for deleted source files #1194
Merged
Conversation
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
ahoppen
force-pushed
the
check-index-up-to-date
branch
from
35b55d6 to
c6c3d74
Compare
ahoppen
force-pushed
the
check-index-up-to-date
branch
2 times, most recently
from
4aade6c to
de48289
Compare
ahoppen
changed the title
ahoppen
force-pushed
the
check-index-up-to-date
branch
from
de48289 to
f7952fc
Compare
|
@swift-ci Please test |
bnbarham
approved these changes
May 1, 2024
| @@ -257,15 +254,14 @@ extension SourceKitLSPServer { | |||
|
|
|||
| let syntacticTests = try await languageService.syntacticDocumentTests(for: req.textDocument.uri) | |||
|
|
|||
| if let index = workspace.index { | |||
| if let index = workspace.index(checkedFor: .imMemoryModifiedFiles(documentManager)) { | |||
There was a problem hiding this comment.
Suggested change
| if let index = workspace.index(checkedFor: .imMemoryModifiedFiles(documentManager)) { | |
| if let index = workspace.index(checkedFor: .inMemoryModifiedFiles(documentManager)) { |
Weirdly this is the first time I noticed the misspelling (despite there being many before this).
This introduces an abstraction layer around `IndexStoreDB` (yes, I known another one …) that consults the underlying `IndexStoreDB` and then checks whether the entries are up-to-date with respect to some `IndexCheckLevel`. Requests can specify how picky they want to be about declaring results from the index out-of-date. The default choice right now is to not include index entries from source files that have been deleted (because those are definitely from lingering unit files) but include results even if the source file has been modified after it was last indexed. We do include results from files that have been modified since they were last indexed because: When a file gets modified, it's likely that some of the line:column locations in it are still correct – eg. if only one line is modified and if lines are inserted/deleted all locations above are still correct. For locations that are out of date, showing stale results is one of the best ways of communicating to the user that the index is out-of-date and that they need to rebuild. We might want to reconsider this default when we have background indexing. rdar://125230833 rdar://126622963
ahoppen
force-pushed
the
check-index-up-to-date
branch
from
f7952fc to
f23d5d6
Compare
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
1 similar comment
|
@swift-ci Please test Windows |
|
@swift-ci Please test |
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.
This introduces an abstraction layer around
IndexStoreDB(yes, I known another one …) that consults the underlyingIndexStoreDBand then checks whether the entries are up-to-date with respect to someIndexCheckLevel. Requests can specify how picky they want to be about declaring results from the index out-of-date.The default choice right now is to not include index entries from source files that have been deleted (because those are definitely from lingering unit files) but include results even if the source file has been modified after it was last indexed. We do include results from files that have been modified since they were last indexed because: When a file gets modified, it's likely that some of the line:column locations in it are still correct – eg. if only one line is modified and if lines are inserted/deleted all locations above are still correct. For locations that are out of date, showing stale results is one of the best ways of communicating to the user that the index is out-of-date and that they need to rebuild. We might want to reconsider this default when we have background indexing.
rdar://125230833
rdar://126622963