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
The signposts aren’t easily visible in the log (you need to add `--signpost` to `log show`) and don’t get logged on non-Darwin platforms at all. Add logging for it.
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.
Waiting for the indexstore-db to be updated is cheaper than potentially not knowing about unit files, which causes the corresponding source files to be re-indexed.
rdar://128645743
We need this function anyway to escalate process priorities when we set `nice`ness values for them. It also simplifies the task scheduler and I’m hoping that it fixes a non-deterministic failure that causes task priority elevation to not work properly.
Turns out that some of logging from task scheduler would have been useful to debug a recent test failure. This adds some logging into `TaskScheduler` again and, most importantly, adds log messages to `ClosureTaskDescription` in `TaskSchedulerTests`.
We used to only watch for file creation and deletion because that might modify build settings but for background indexing, we also need to watch for changes to the files, so we can invalidate the up-to-date status of the target.
In SourceKit-LSP, we can get into the following situation:
1. We open A.swift
2. We issue a request for A.swift, the request takes a while to execute
3. The dependencies of A.swift are updated, which causes us to reopen the document in sourcekitd, so that the AST is rebuilt
4. This shouldn’t cause the request from (2) to be cancelled. We should continue executing it and only re-open the document after the request from (2) has finished
rdar://127475366
This allows us to run `sourcekit-lsp index --project /path/to/project` to index a project. Intended to debugging purposes, eg.
- Profile the time it takes to index a project
- See if the project can be indexed successfully
- Look at signposts generated during indexing in Instruments to see whether indexing or preparation is the bottleneck and how well we can parallelize tasks.
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#1265
