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
When the user opens documents from three targets A, B, and C in quick succession, then we don’t want to schedule preparation of wait until A *and* B are finished preparing before preparing C.
Instead, we want to
- Finish for preparation of A to finish if it has already started by the time the file in C is opened. This is done so we always make progress during preparation and don’t get into a scenario where preparation is always cancelled if a user switches between two targets more quickly than it takes to prepare those targets.
- Not prepare B because it is no longer relevant and we haven’t started any progress here. Essentially, we pretend that the hop to B never happened.
Whenever we get request for a document, open it or edit it, trigger a preparation of its target, but don’t block any interaction based on it. This should ensure that the target is usually prepared when the user is interacting with it.
We need to track the preparation status of targets somewhat accurately in `SemanticIndexManager`, so we don’t unnecessarily re-prepare a target. When updating the index store, it is acceptable to schedule another `UpdateIndexStoreTaskDescription` because it will early exit based on an `mtime` check with the unit file. Null builds of a target take significantly longer and thus we want to avoid them.
Fixes#1252
rdar://127474003
When `SwiftPMBuildSystem` operates on a ` .index-build` directory, it owns the checkouts and is thus also allowed to resolve the package versions. This is necessary
Instead of asking for build settings of a file, the build system manager asks for the targets of a file and then asks for the build settings of that file in a specific target. This has two advantages:
- We know about targets and can prepare the targets for background indexing
- Once we support build systems in which a single file can be part of multiple targets, we can have a centralized place that picks preferred targets for a file, eg. based on user configuration
Previously, `SwiftPMBuildSystem` would report `.unhandled` as the file handling capability for `Package.swift`. In single workspace-folder setups, this was not an issue because we would always default to using the build system of the first/only workspace folder, which was the only `SwiftPMBuildSystem` and then returned compiler arguments despite saying that it couldn’t handle `Package.swift`.
This, however, breaks if you have a setup with multi workspace folders, where we can’t rely on the first workspace folder being able to provide build settings for the package manifest.
To fix this, report `.handled` file handling capability for all files that `SwiftPMBuildSystem` can compute build settings for.
Fixes#1210
rdar://127351614
`SwiftPMBuildSystem.testFiles()` returned all source files in the package, including files of package dependencies. This caused us to index those files for tests in the syntactic test index, which we should not.
Make `SwiftPMBuildSystem.testFiles` only return files from the root package.
Also add test infrastructure to be able to test cross-package functionality.
rdar://126965614
When the client sends us `workspace/didChangeWatchedFiles` notification of an updated `.swift` file, we should refresh the other open files in that module since they might be referencing functions from that updated file.
If a `.swiftmodule` file has been updated, we refresh all the files within the package since they might import that module. Technically, we would only need to refresh files that are in module that are downstream of the updated module but we don’t currently have that information easily available from SwiftPM. Also, usually, if the client has a file from a low-level module open, he’ll be working on that module which means that such an optimization won’t help. The real solution here is to wait for us to finish preparation (which we would exactly know when it finishes since sourcekit-lsp would schedule it) but for that we need to implement background preparation.
Fixes#620Fixes#1116
rdar://99329579
rdar://123971779
This workspace-wide syntactic test index is used for two purposes:
- It is used for XCTests instead of the semantic index for files that have on-disk or in-memory modifications to files
- It is uses for swift-testing tests, which are only discovered syntactically.
rdar://119191037
This allows us to express that `body` will run on the same actor isolation domain as the caller of `orLog`, which effectively makes `orLog` usable from actors again.
All other types that conform to `BuildSystem` (which in sourcekit-lsp terms is something that can provide compiler arguments) had the `BuildSystem` suffix. `SwiftPMWorkspace` was an oddity here and was easily confused with the `Workspace` term in LSP, which essentially represents a single root folder that is being opened.
