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
Absolute search paths were being ignored without logging, which makes it
somewhat difficult to diagnose. Log when they're skipped.
Also remove a duplicate options merging block - both
`createWorkspaceWithInferredBuildServer` and `findImplicitWorkspace`
(the only callers of `createWorkspace`) already merge in the workspace
options.
Until we have better measurements that would motivate a different batching strategy, copying the driver’s batch size seems like the most reasonable thing to do.
When I added the log structure to `build/logMessage` in #2022 I must have assumed that the entire BSP notifciation was an extension defined by SourceKit-LSP and didn’t realized that this was actually a change that made the notification non-compliant with BSP. Change it up a little bit to make it compliant again.
If a build server copies files (eg. header) to the build directory during preparation and those copied files are referenced for semantic functionality, we would currently jump to the file in the build directory. Teach SourceKit-LSP about files that are copied during preparation and if we detect that we are jumping to such a file, jump to the original file instead.
So far only the definition request checks the copied file paths. Adding support for copied file paths in the other requests will be a follow-up change.
When the BSP server fails to initialize, it can’t give us any compiler arguments and we won’t be able to provide semantic functionality. Show the message to the user so they can do something about fixing it instead having to dig into SourceKit-LSP logs.
Two improvements to the logic that determines if we need to reload the package on a file change:
1. Only reload a package if the modified package manifest or Package.resolved is in the root of the package folder. This is relevant if we have a multi-root workspace, in which currently a single change to a package manifest or Package.resolved causes all packages to get reloaded.
2. While I was at it, I noticed that we didn’t properly handle version-specific package manifests. Also trigger a package reload if a version-specific package manifest is modified, created or deleted.
We already had logic to retry loading a package manifest if writing the output-file-map failed. This only covered errors thrown from Foundation but I was seeing similar errors from TSC. Cover those as well.
If a call in `reloadPackageAssumingOnPackageLoadingQueue` throws, we weren’t getting to the end of it and would thus never end the signpost started within. Move the `endInterval` call up ensure it is always ended.
Found this while investigating https://ci-external.swift.org/job/swift-PR-windows/44247/console, which failed SourceKit-LSP testing because PackageA could not be loaded due to
```
Initial package loading: invalid access to C:\Users\swift-ci\jenkins\workspace\swift-PR-windows\build\tmp\lsp-test\924F7085\PackageA\.build\index-build\x86_64-unknown-windows-msvc\debug\MyLibrary.build\output-file-map.json
```
- I think there are valid calls with mixing inline and trailing closures (notably `Debouncer`), so I’m considering whether we should disable that rule.
- The `forEach` rule is a little annoying because we have `forEach` on `SKDResponseArray`. But it caught two cases of using `forEach` on arrays, so I think it’s worth keeping.
Having `BuildSettingsLogger` can be problematic if we launch multple `SourceKitLSPServer` instances in the same process (such as during testing). In that case it could happen that a previous `SourceKitLSPServer` instance logs build settings and then the second instance doesn’t log its build settings (if they are the same) because the shared logger has already logged them.
This issue is resolved by scoping `BuildSettingsLogger` to the lifetime of `BuildServerManager` (ie. one per workspace).
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.
