`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
