It is important that we cache this because we might find a lot of symbols in the same container for eg. workspace symbols (eg. consider many symbols in the same C++ namespace). If we didn't cache this value, then we would need to perform a `primaryDefinitionOrDeclarationOccurrence` lookup for all of these containers, which is expensive.
For example, searching for `only` in SourceKit-LSP’s codebase used to not return results in more than 20s (after which I gave up) and now returns >8000 results in <2s.
rdar://141412138
`inProgressTextDocumentRequests` is supposed to only be accessed on `textDocumentTrackingQueue` but we were accessing it outside of that queue. Because of this, we might try to remove requests from `inProgressTextDocumentRequests` before adding them, which would cause them to stay in the list indefinitely.
Consider the following scenario: A project has target A containing A.swift an target B containing B.swift. B.swift is a symlink to A.swift. When A.swift is modified, both the dependencies of A and B need to be marked as having an out-of-date preparation status, not just A.
When `\{` is included inside an LSP placeholder, in VS Code will insert `\{` verbatim. At least in VS Code, we only need to escape the closing brace.
While at it, also escape `$` and `\` inside placeholders, according to the LSP spec.
Since we enabled background indexing by default, the user is no longer explicitly opting into it. A user might be exclusively working with compilation database projects or BSP server without background indexing support and thus not care that we switched the background indexing default. We shouldn’t bother them with a warning message every time they launch sourcekit-lsp.
`generateBuildGraph` was named misleadingly because the primary purpose of these tasks was to schedule indexing tasks and generating the build graph was just a necessary step for this. Also update it to take into account that multiple tasks scheduling indexing tasks might be running in parallel.
`$/setTrace` changes a global configuration setting but it doesn't affect the result of any other request. To avoid blocking other requests on a `$/setTrace` notification the client might send during launch, we treat it as a freestanding message.
Also, we don't do anything with this notification at the moment, so it doesn't matter.
This is more performant. In particular adding a new task to `indexingQueue` for each file to rescan can hit the quadratic issue in `AsyncQueue` if many files were changed.
`extension MyTask: AnyTask {}` includes an occurrence of `MyTask.cancel` to mark it as an override of `AnyTask.cancel` but we shouldn't show the extension in the call hierarchy.
As the user types, we filter the code completion results. Cancelling the completion request on every keystroke means that we will never build the initial list of completion results for this code completion session if building that list takes longer than the user's typing cadence (eg. for global completions) and we will thus not show any completions.
This resolves <https://github.com/swiftlang/sourcekit-lsp/issues/1788>,
following the discussion of alternatives on
<https://github.com/swiftlang/sourcekit-lsp/pulls/1789>. The bulk of the
change updates the translation from SourceKit placeholders to LSP
placeholders to handle nesting. The `CodeCompletionSession` also passes
a new custom formatter to the swift-syntax expansion routine, which
disables the transformation to trailing closures.
Adding an item to `AsyncQueue` was 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.
While we can't fix the quadratic performance issue in general, we can resolve the quadratic issue of `AsyncQueue<Serial>` by making a new task only depend on the last item in the queue, which then transitively depends on all the previous items. `AsyncQueue<Serial>` are the queues that are most likely to contain many items.
Fixes#1725
rdar://137886469
We made quite a few fixes recently to make sure that path handling works correctly using `URL` on Windows. Use `URL` in most places to have a single type that represents file paths instead of sometimes using `AbsolutePath`.
While doing so, also remove usages of `TSCBasic.FileSystem` an `InMemoryFileSystem`. The pattern of using `InMemoryFileSystem` for tests was never consistently used and it was a little confusing that some types took a `FileSystem` parameter while other always assumed to work on the local file system.
