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 were mixing the up-to-date status and in-progress status of an index task in `SemanticIndexManager`. This meant that a single `QueuedTask` in the task scheduler could be needed for eg. both preparation for editor functionality in a file of that target and to re-index a file in that target. This dual ownership made it unclear, which caller would be entitled to cancel the task. Furthermore, we needed to duplicate some logic from the preparation task dependencies in `SemanticIndexManager.prepare`.
To simplify things:
- Split the up-to-date status and the in-progress status into two different data structures
- Make the caller of `prepare` and `scheduleIndex` responsible for cancellation of the task it has scheduled. `TaskScheduler` might receive more scheduled tasks this way but the additional tasks should all be no-ops because the status is known to be up-to-date when they execute.
We could get `DocumentDiagnosticsRequest` triggered from file changes or old preparation operations during the initial build without actually having re-prepared the target after the file change. Make the test wait until it receives expected diagnostics after the file change.
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 a header is modified, we don’t we want to re-index all main files that include it. Instead, we just want to index one main to effectively re-index the header itself.
I originally implemented re-indexing of all files that include the header but on second thought, headers are like Swift modules, where we also don’t re-index all dependencies either. And if you change a low-level header that’s included by the entire project, you probably don’t want the indexer to go off and re-index the entire project.
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
This follows the general paradigm that callbacks shouldn’t carry much state and instead only notify an observer that state has changed, which the observer can then poll.
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
This meant that if there were two newlines before the declaration, the documentation would be separated to the declaration by one newline and if the declaration was at the start of a line, the declaration would be on the same line as the doc comment, effectively making the documentation part of a comment.
Addresses a few minor comments and the following major ones:
- Add test cases for the syntax refactorings
- Don’t report code actions for refactorings that don’t actually modify the source
- Instead of just looking at the parent of the token of the selected range, walk up the syntax tree to find the syntax node to refactor. This makes the refactorings available in a lot more locations.
Merge the XCTests and swift-testing tests defined in extensions into
their parent TestItems.
This is done as another pass after the TestScanner visitors have walked
the tree.
Fixes#1218
When renaming `func test(foo: Int) {}` to `test2(foo:)`, rename used to report an edit from `foo` to `foo`, which clutters the refactor preview view. We shouldn’t report edits if no text is actually changed.
rdar://127291815
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
