Adding an item to `AsyncQueue<Serial>` is linear in the number of pending queue items, thus adding n items to an `AsyncQueue` before any can execute is in O(n^2). This decision was made intentionally because the primary use case for `AsyncQueue` was to track pending LSP requests, of which we don’t expect to have too many pending requests at any given time.
`SourceKitIndexDelegate` was also using `AsyncQueue` to track the number of pending units to be processed and eg. after indexing SourceKit-LSP, I have seen this grow up to ~20,000. With the quadratic behavior, this explodes time-wise.
Turns out that we don’t actually need to use a queue here at all, an atomic is sufficient and much faster.
Independently, we should consider mitigating the quadratic behavior of `AsyncQueue<Serial>` or `AsyncQueue` in general.
Fixes#1541
rdar://130844901
We forgot to decode the following keys in the custom decode function, which meant that you couldn’t set them using SourceKit-LSP’s `config.json` file.
- `backgroundPreparationMode`
- `sourcekitdRequestTimeout`
In particular this meant that you couldn’t enable the `--experimental-prepare-for-indexing` preparation mode.
Add the necessary decoding functions in `release/6.0` and eliminate the custom decode logic entirely in `main`.
In a project with multiple folders each containing a Package.swift, the
`bestWorkspace` found in `workspaceForDocument(uri:)` was always the
first one encountered.
`fileHandlingCapability(for:)` checks if there are configured targets
for the Package.swift and if there are, the workspace is chosen since
the Package.swift is determined to be part of the workspace. However the
check in `configuredTargets(for:)` always returned a target for any
`Package.swift`, even if that `Package.swift` was not part of the
workspace associated with the BuildSystem.
Ultimately this manifested as code completion not working in all but one
of the Package.swift files in a multi workspace project.
Some work was done in #1210 to address swiftlang/vscode-swift#768, which
is where this issue originated from. However while verifying
swiftlang/vscode-swift#768 I found that #1210 didn't fully address code
completion of `Package.swift` files in multi workspace projects.
Report to clients that the server supports the
`workspace/triggerReindex` request. This lets clients expose this
functionality only if SourceKit-LSP is configured to support it.
`TriggerReindexRequest` was missing from the list of builtinRequests,
which caused the LSP to respond with a methodNotFound error when it
recieved a `workspace/triggerReindex` request.
VS Code does not cancel semantic tokens requests. If a source file gets into a state where an AST build takes very long, this can cause us to wait for the semantic tokens from sourcekitd for a few minutes, effectively blocking all other semantic functionality in that file.
To circumvent this problem (or any other problem where an editor might not be cancelling requests they are no longer interested in) add a maximum request duration for SourceKitD requests, defaulting to 2 minutes.
rdar://130948453
It is possible to have two identically named suites in two different
test targets. These were being erroniously rolled up in to the same
parent TestItem.
Disambiguate these TestItems by prepending the module name. This has the
added benefit of making the TestItem IDs a fully qualified name that can
be passed to `swift test`.
The module name is pulled from the compiler arguments for the target. If
no module name can be found we fall back to the `targetID` for the
`ConfiguredTarget`.
This allows us to flip the default in the future more easily. It also allows users to disable background indexing when it’s enabled by default.
rdar://130280855
# Conflicts:
# Tests/SourceKitLSPTests/BackgroundIndexingTests.swift
The idea here is to unify the different ways in which we can currently set options on SourceKit-LSP in a scalable way: Environment variables, command line arguments to `sourcekit-lsp` and initialization options.
The idea is that a user can define a `~/.sourcekit-lsp/.sourcekit-lsp` file (we store logs in `~/.sourcekit-lsp/logs` on non-Darwin platforms), which will be used as the default configuration for all SourceKit-LSP instances. They can also place a `.sourcekit-lsp` file in the root of a workspace to configure SourceKit-LSP for that project specifically, eg. setting arguments that need to be passed to `swift build` for that project and which thus also need to be set on SourceKit-LSP.
For compatibility reasons, I’m mapping the existing command line options into the new options structure for now. I hope to delete the command line arguments in the future and solely rely on `.sourcekit-lsp` configuration files.
Environment variable will be migrated to `.sourcekit-lsp` in a follow-up commit.
# Conflicts:
# Sources/SourceKitLSP/SourceKitLSPServer+Options.swift
# Sources/SourceKitLSP/Swift/SwiftLanguageService.swift
# Sources/sourcekit-lsp/SourceKitLSP.swift
# Tests/SourceKitLSPTests/BackgroundIndexingTests.swift
# Tests/SourceKitLSPTests/ExecuteCommandTests.swift
This extension was added for VS Code but never used. Let’s remove it in favor of workspace-specific configuration files.
# Conflicts:
# Sources/SourceKitLSP/SourceKitLSPServer.swift
clangd uses a completely different semantic token legend than SourceKit-LSP (it doesn’t even adhere to the ordering of the pre-defined token types) but we were passing index offsets from clangd through assuming that clangd uses the same legend, which was incorrect.
When retrieving semantic tokens from clangd, translate the semantic tokens from clangd’s legend to SourceKit-LSP’s legend.
rdar://129895062
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 were sending `SIGINT` to `swift-frontend` processes if they didn’t terminate after 2 minutes. However, `swift-frontend` doesn’t listen to `SIGINT`.
If a task running `waitUntilExitStoppingProcessOnTaskCancellation` is cancelled and the process doesn’t terminate on a `SIGINT` after 2 seconds, kill it.
rdar://130103147
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`.
rdar://130103181
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
Currently the name of the command is `source-kit-lsp` in `sourcekit-lsp --help` output:
```
❯ sourcekit-lsp --help
OVERVIEW: Language Server Protocol implementation for Swift and C-based languages
USAGE: source-kit-lsp <options> <subcommand>
```
