Skip to content

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

Merged
merged 2 commits into from
May 22, 2024
Merged

Conversation

ahoppen
Copy link
Member

@ahoppen ahoppen commented May 22, 2024

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

ahoppen added 2 commits May 21, 2024 22:09
…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
@ahoppen ahoppen requested review from bnbarham and hamishknight May 22, 2024 05:18
@ahoppen ahoppen requested a review from benlangmuir as a code owner May 22, 2024 05:18
@ahoppen
Copy link
Member Author

ahoppen commented May 22, 2024

@swift-ci Please test

@ahoppen ahoppen merged commit 30a16ec into swiftlang:main May 22, 2024
3 checks passed
@ahoppen ahoppen deleted the index-log branch May 22, 2024 13:41
Comment on lines +88 to +91
// 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)
Copy link
Contributor

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?

Copy link
Member Author

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

ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this pull request May 22, 2024
ahoppen added a commit to ahoppen/sourcekit-lsp that referenced this pull request May 22, 2024
ahoppen added a commit that referenced this pull request May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Show build graph generation in work done progress Send trace message to editor if indexing of a file fails
2 participants