-
Notifications
You must be signed in to change notification settings - Fork 314
Produce an index log for the client #1326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ets being prepared in the work done progress
This allows a user of SourceKit-LSP to inspect the result of background indexing. This allows a user of SourceKit-LSP to inspect the result of background indexing. I think this gives useful insights into what SourceKit-LSP is indexing and why/how it fails, if it fails, also for users of SourceKit-LSP. rdar://127474136 Fixes swiftlang#1265
@swift-ci Please test |
// We can get into a situation where queuedIndexTasks < indexTasks.count if we haven't processed all | ||
// `indexTasksWereScheduled` calls yet but the semantic index managers already track them in their in-progress tasks. | ||
// Clip the finished tasks to 0 because showing a negative number there looks stupid. | ||
let finishedTasks = max(queuedIndexTasks - indexTasks.count, 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just realized that queuedIndexTasks
will be artificially high if you schedule a re-index for a file multiple times, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. It’s mitigated a little bit by the fact that we don’t increment the queuedIndexTasks
from scheduleIndexing
for files that we know are up-to-date.
And at least in the current design, I do want to increment the queuedIndexTasks
for each file to index eg. in the following scenario
- Schedule indexing of A.swift and B.swift -> 0 / 2
- Indexing of A.swift finishes -> 1 / 2
- A.swift is modified and should be indexed again -> 1 / 3
- B.swift finishes indexing -> 2 / 3
- A.swift finishes indexing for the second time -> 3 / 3 -> Status disappears
The alternative would be to decrement the numerator when A.swift is modified but I think that’s confusing.
But it is worth guarding against the following scenario:
- Schedule indexing of A.swift and B.swift -> 0 / 2
- A.swift is modified and should be indexed again -> Should still be 0 / 2, currently would be not 1 / 3
- A.swift finishes indexing -> 1 / 2
- B.swift finishes indexing -> 2 / 2 -> Status disappears
This allows a user of SourceKit-LSP to inspect the result of background indexing. I think this gives useful insights into what SourceKit-LSP is indexing and why/how it fails, if it fails, also for users of SourceKit-LSP.
rdar://127474136
rdar://128071435
Fixes #1265
Fixes #1299