We previously waited for the initialization response from the build server during the creation of a `Workspace` so that we could create a `SemanticIndexManager` with the index store path etc. that was returned by the `build/initialize` response. This caused all functionality (including syntactic) of SourceKit-LSP to be blocked until the build server was initialized.
Change the computation of the `SemanticIndexManager` and related types to happen in the background so that we can provide functionality that doesn’t rely on the build server immediately.
Fixes#2304
If a source file is part of multiple targets, we should index it in the context of all of those targets because the different targets may produce different USRs since they might use different build settings to interpret the file.
When the client supports it, communicate the structure of tasks that were stared during background indexing or by the build server to the client. If there are multiple operations happening in parallel, this allows the client to display them in separate log tracks instead of interspersing them with the emoji prefixes like we do today.
`generateBuildGraph` was named misleadingly because the primary purpose of these tasks was to schedule indexing tasks and generating the build graph was just a necessary step for this. Also update it to take into account that multiple tasks scheduling indexing tasks might be running in parallel.
This allows us to flip the default in the future more easily. It also allows users to disable background indexing when it’s enabled by default.
rdar://130280855
This allows VS Code to detect when sourcekitd has crashed and prompt the user to gather a diagnostic report + file an issue about the crash.
rdar://129678779
Fixes#1476
The `showActivePreparationTasksInProgress` didn’t turn out to be terribly useful and with the streaming index log (https://github.com/apple/sourcekit-lsp/pull/1382), we should have the functionality to view which index tasks are currently running. So, we should remove the feature.
rdar://129109830
I was wondering for a while why we were showing “Indexing 0 / 0” as the index progress. I think it’s if we only have a preparation task but no index tasks running. I’m not entirely sure how this happens because preparation should only happen for two reasons:
- We are preparing a target so we can index a files -> We should have an active index task
- We are preparing a file for editor functionality of the current file -> we should have a `inProgressPrepareForEditorTask`
Maybe I’ll understand it once we have this change in. It seems like a worthwhile change in any way.
Background indexing probably won’t be the last experimental feature in sourcekit-lsp that we want to gate behind a feature flag. Instead of adding new parameters ad-hoc, introduce a general notion of experimental features.
While `SemanticIndexManager.inProgressPrepareForEditorTask` is not `nil`, show a work done progress in the editor that the current file is being prepared for editor functionality.
I decided to use the indexing progress indicator for this for now because I think it’s too spammy if SourceKit-LSP has two different progress indicators for preparation and indexing. I’ll need to see how this feels like in practice.
rdar://128722609
Rebuilding the build graph can take a while (initial loading of the build graph takes ~7s for sourcekit-lsp) and it’s good to show some progress during this time.
We were mixing the up-to-date status and in-progress status of an index task in `SemanticIndexManager`. This meant that a single `QueuedTask` in the task scheduler could be needed for eg. both preparation for editor functionality in a file of that target and to re-index a file in that target. This dual ownership made it unclear, which caller would be entitled to cancel the task. Furthermore, we needed to duplicate some logic from the preparation task dependencies in `SemanticIndexManager.prepare`.
To simplify things:
- Split the up-to-date status and the in-progress status into two different data structures
- Make the caller of `prepare` and `scheduleIndex` responsible for cancellation of the task it has scheduled. `TaskScheduler` might receive more scheduled tasks this way but the additional tasks should all be no-ops because the status is known to be up-to-date when they execute.
This makes it a lot easier to work on background indexing because you can easily see how background indexing is making progress.
Resolves#1257
rdar://127474057
