Users should not need to rely on this request. The index should always be updated automatically in the background. Having to invoke this request manes there is a bug in SourceKit-LSP's automatic re-indexing. It does, however, offer a workaround to re-index files when such a bug occurs where otherwise there would be no workaround.
rdar://127476221
Resolves#1263
We need to watch for changes to `Package.resolved` so that we can update the dependency checkouts in `.index-build` when the user runs `swift package update`.
This allows VS Code to detect when sourcekitd has crashed and prompt the user to gather a diagnostic report + file an issue about the crash.
rdar://129678779
Fixes#1476
The key issue here was that we were looking at the symbol occurrence that had the `overrideOf` role and were using this symbol occurrence to also check that it’s a child of one of the receiver types. But if the protocol requirement is satisfied in an extension, we have an implicit symbol occurrence at the location where the protocol requirement is stated but the real declaration’s occurrence is inside the extension. The fix here is to just extract the USR from the `overrideOf` relation and then do another index lookup to find the symbol’s definition.
rdar://129412428
- Rename methods to highlight that we’re talking about generated interfaces here, not `.swiftinterface` files
- Don’t open the generated interface in `documentManager`. Opening documents in `documentManager` should only be done by the `textDocument/didOpen` notification from the LSP client. Otherwise we might indefinitely keep the document in the document manager
- After getting the generated interface from sourcekitd, close the document in sourcekitd again. We don’t provide semantic functionality in the generated interface yet, so we can’t interact with the generated interface path. Before, we left it open in sourcekitd indefinitely.
- A couple of code simplifications.
Fixes#878
rdar://116705653
Since the `Atomic*` types can not be marked as `Sendable` (because they aren’t C structs), we can change the variables to constants and can remove `nonisolated(unsafe)`.
This allows us to fix a toolchain when using a `SwiftPMBuildSystem`, which is critical to ensure that a target gets prepared using the same toolchain that is used to index it and that is used for sourcekitd.
We used C atomics but these were allocated as Swift variables. Even thought they were atomic, concurrent accesses to them could violate Swift’s exclusivity laws, raising thread sanitizer errors.
Allocate the C atomics using malloc to fix this problem.
rdar://129170128
This was causing a non-deterministic test failure: When target preparation finishes while a diagnostic request is in progress, it will re-open the document, which calls `DiagnosticReportManager.removeItemsFromCache` for that document’s URI. With the old implementation, we would thus cancel the diagnostics sourcekitd request and return a cancelled error to the diagnostics LSP request.
While doing this, I also realized that there was a race condition: Document re-opening would happen outside of the SourceKit-LSP message handling queue and could thus run concurrently to any other request. This means that a sourcekitd request could run after `reopenDocument` had closed the document but before it was opened again. Introduce an internal reopen request that can be handled on the main message handling queue and thus doesn’t have this problem
This also means that you can use the index log to view which tasks are currently being executed.
Since we only have a single log stream we can write to, I decided to prefix every line in the index log with two colored emojis that an easy visual association of every log line to the task that generated them.
If the editor has support for this LSP extension, it can create a separate output view for the index log.
For example, in VS Code, we could have one output view for the standard LSP logging (which are the messages between VS Code and SourceKit-LSP if verbose logging is enabled in VS Code) and a separate log that shows information about background indexing.
rdar://128572032
The container name isn’t displayed very prominently and it’s easy to miss. I think the call hierarchy looks nicer when we prepend the container name with language-specific logic.
rdar://128396648
Background indexing probably won’t be the last experimental feature in sourcekit-lsp that we want to gate behind a feature flag. Instead of adding new parameters ad-hoc, introduce a general notion of experimental features.
This shows up nicer in Instruments because it doesn’t open a new lane for every signpost. Instead, they all share the same lane. Concurrent signposts are still shown as overlapping.
If the user has enabled background indexing in sourcekit-lsp but opens a project that doesn’t support background indexing (compilation database, build server), we should show a message after opening the workspace, informing the user that background indexing is only supported in SwiftPM projects at the moment.
Fixes#1255
rdar://127474711
When looking for a workspace that can handle a file, we were creating full-fledged workspaces along the way, which we would then discard if they couldn’t handle the file being opened. This had multiple problems:
1. When background indexing is enabled, it caused semantic indexing of the workspace, which wrote files to a `.index-build` directory and was a waste of work
2. When background indexing is enabled, it caused package resolution, which also created a `.index-build` folder to be created
3. It caused a syntactic test index of the workspace, which was a waste of work.
To fix this, do multiple things:
1. When creating a workspace, add a check right after build system creation. This allows us to early exit if the build system can’t handle the file and prevents us from generating the `Workspace`, fixing (1) and (3)
2. Don’t call `reloadPackage` when creating a `SwiftPMWorkspace`. Instead, explicitly call `generateBuildGraph` once we committed to creating the workspace.
The file was a little large and contained multiple types that can easily be split off. Now you can scroll to the top of the file and see the members of `SourceKitLSPServer`.
