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.
On Darwin platforms, this fixes the following problem: indexstore-db by itself returns realpaths but the build system might be using standardized Darwin paths (eg. realpath is `/private/tmp` but the standardized path is `/tmp`). Because of this, when inferring the main file for a file, we might get a URI that the build system doesn’t know about. To fix this, if the realpath that indexstore-db returns could not be found in the build system's source files but the standardized path is part of the source files, use the standardized path instead.
This fixes the following problem, which caused files to get indexed twice: You open a workspace, which schedules initial indexing. While we are waiting for the build graph generation from the build server, the build servers sends `buildTarget/didChange` notification to SourceKit-LSP (eg. because it has finished loading the build graph). This causes all files in the changed targets to be scheduled for re-indexing since new files might be present in the updated targets. And since we have already started indexing of those files, we assumed that we need to index them again because the contents might have changed.
To fix this, keep track of the file’s modification time at the time at which we scheduled indexing for it. If that time hasn’t changed and we have an in-progress indexing operation for it, there is no need to schedule another one.
For each file in the changed targets, we still check whether it has an up-to-date unit based on timestamps. The important thing for this change is that we start indexing files for which we only receive build settings after an update from the build server.
We were blocking the initialization response on `self.buildSystemManager.testFiles`, which requires the list of test files to be determined. Make that operation asynchronous so that a slow build server can’t take down all of SourceKit-LSP.
This can be useful to IDEs that want to perform some additional semantic processing of source files, which requires knowledge of a file’s build settings.
Otherwise, we return the failed diagnostic report even after sourcekitd has been restored.
Also, make sure that we don't show the `semantic editor is disabled` error to users.
`pollForUnitChangesAndWait` is a costly operation since it iterates through all the unit files on the file system. We should only run it during initial indexing (where we might need to build the initial indexstore-db) but not for any subsequent indexing calls.
Otherwise, the close does not get handled by the SourceKit plugin. In practice, it doesn’t matter too much because the SourceKit plugin will implicitly close the last completion session when a new one is opened but we should fix this.
- Clarify that this must only be called with documents that are open in SourceKit-LSP and add a check for that.
- Allow sending `null` to indicate that no SourceKit-LSP document is currently active.
- Cancel preparation tasks for other workspaces that don’t contain the currently active document.
This request allows IDEs to disable SourceKit-LSP’s background indexing functionality when it requires all compute resources for other, more interactive, tasks.
SourceKit-LSP prepares the currently active file for editor functionality and currently infers the currently active document from whichever received the last `TextDocumentRequest`.
If an editor is capable of doing so, it should be able to report the document that the user currently has focused so that SourceKit-LSP does not have to infer this information from other requests.
Also clean up some handling code for experimental capabilities.
If the build system is sending us with `buildTarget/didChange`, we would always create processor count * 4 new entries in the `indexingQueue` to rescan those files, if they are up-to-date. This can be quite wasteful if the underlying files didn’t actually change. Do a quick scan up-front to check if the files actually need to be re-scanned up-front.
