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.
We weren’t logging requests sent to a `TestSourceKitLSPClient` because we were assuming that `JSONRPCConnection` logs those requests in `SourceKitLSPServer`. But no logging happens in `LocalConnection`, which `TestSourceKitLSPClient` uses.
Since `LangaugeServerProtcol` can’t depend on `LSPLogging`, move the type to `LSPTestsSupport`.
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
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
Implements an initial background index when the project is opened.
The following will be implemented in follow-up PRs:
- Resolving package dependencies
- Preparing dependent modules
- Watching for file updates
This allows us to determine the toolchain to use during background indexing. It also moves toolchain selection closer to the build system, which is good because when we support multiple toolchains for a single workspace, the build system is what decides which toolchain to use for which document.
This introduces an abstraction layer around `IndexStoreDB` (yes, I known another one …) that consults the underlying `IndexStoreDB` and then checks whether the entries are up-to-date with respect to some `IndexCheckLevel`. Requests can specify how picky they want to be about declaring results from the index out-of-date.
The default choice right now is to not include index entries from source files that have been deleted (because those are definitely from lingering unit files) but include results even if the source file has been modified after it was last indexed. We do include results from files that have been modified since they were last indexed because: When a file gets modified, it's likely that some of the line:column locations in it are still correct – eg. if only one line is modified and if lines are inserted/deleted all locations above are still correct. For locations that are out of date, showing stale results is one of the best ways of communicating to the user that the index is out-of-date and that they need to rebuild. We might want to reconsider this default when we have background indexing.
rdar://125230833
rdar://126622963
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
With https://github.com/apple/swift/pull/72930 we can use the `containedBy` instead of `calledBy` relation for the call hierarchy, which allows us to show unapplied function references in the call hierarchy as well.
rdar://123769825
For example when trying to go-to-definition to `filter` on `Array`, we get a USR `s:s14_ArrayProtocolPsE6filterySay7ElementQzGSbAEKXEKF::SYNTHESIZED::s:Sa`. We were trying to look it up in the index, which failed because synthesized extension methods are not indexed.
Instead, consult the `module` and `groupName` that `sourcekitd` returns in the cursor info request to decide which module to jump to.
rdar://126240558
Eg. when requesting type hierarchy of a class when the project hasn’t been built, sourcekit-lsp returns an empty array. That causes VS Code to fail with very ambiguous error messages
- MISSING provider
- Cannot read properties of null (reading 'kind')
To work around this, instead of returning an empty array, return `nil` instead.
rdar://126228814
Eg. if we have the following, and we get the call hierarchy of `foo`, we only want to show `bar` once, with multiple `fromRanges` instead of having two entries for `bar` in the call hierarchy.
```swift
func foo() {}
func bar() {
foo()
foo()
}
```
This ways the client doesn’t need to create a hierarchical structure using the container names. It is also more flexible and allows nesting of test suites + the addition of labels and tags for swift-testing.
The data structure for `TestItem` has been heavily inspired by VS Code’s `TestItem` for the test explorer, which should make it fairly straightforward to integrate these results into the VS Code test explorer.
The naming was quite inconsistent here. Let’s rename these to `LanguageService` to highlight that they belong together.
- ToolchainLanguageServer -> LanguageService
- SwiftLanguageServer -> SwiftLanguageService
- ClangLanguageServerShim -> ClangLanguageService
