This refactoring now takes a `Syntax` parameter. We don't actually
need to change anything else to handle placeholder expansion for
macro expansion completions since they get parsed as function calls.
There is only one real class that implements the `SourceKitD` protocol, so there really isn’t any need for the protocol + class split at all. Unify them to make code simpler to reason about.
Otherwise, the close does not get handled by the SourceKit plugin. In practice, it doesn’t matter too much because the SourceKit plugin will implicitly close the last completion session when a new one is opened but we should fix this.
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.
`LineTable.replace` did not actually validate that the edit is in range. This could cause crashes of SourceKit-LSP if the editor is sending us bogus edits. Validate the position, like we do in all the other position conversions and log a fault if the edit is out-of-range.
While fixing this, I found a couple more places where line table accesses were not properly guarded. I migrated them to safe alternatives as well.
rdar://138962353
Even after sending the `dependencyUpdated` request to sourcekitd, the code completion session has state from before the AST update. Close it and open a new code completion session on the next completion request.
Do one of the following for every `FIXME` or `TODO` comment
- Add an issue that tracks the task
- Remove the comment if we are not planning to address it
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
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.
Instead of returning `nil` to indicate that the position conversion failed, log a fault and perform a best-effort recovery.
I think this allows us to perform better recovery and also makes code calling these position conversions a lot simpler because it doesn’t need to make decisions about what to do if position conversions fail.
Instead of logging errors in position translation ad-hoc at the caller’s side (and ofter forgetting to do so), log these errors in `LineTable`. To be able to debug where the position conversion error is coming from, also log the file name and line number of the caller.
rdar://125545620
When translating editor placeholders to snippets, we should not include internal parameter names into the snippet. The problem is that once you leave snippet editing mode (essentially by moving the cursor to any place that’s not the snippet, eg. by typing a string literal for one of the parameters or moving the cursor), all snippets become verbatim text. And then it’s impossible to tell whether `paramName: ` was an annotation inside the snippet describing the internal parameter’s name or the external parameter label.
rdar://123772474
Editors other than Xcode don’t have a notion of editor placeholders or their expansion, so we can’t produce results with editor placeholders and expect the user to expand them while completing the function arguments.
Instead, expand all trailing closure placeholders when producing the code completion results.
The generated expansion is currently not formatted with respect to the file’s indentaiton. Since we don’t want to launch `swift-format` for every completion item, this formatting will need to be done using `BasicFormat` which needs to infer the file’s indentation. Doing so will be non-trivial work on its own and will be done in a follow-up PR.
rdar://121130170
Naming types in sourcekitd_functions.h `sourcekit_api_` instead of `sourcekitd_` indicates that these are types to be used with dynamically loaded sourcekitd libraries. It avoids confusion if sourcekitd is also linked, which adds the `sourcekitd_` symbols.
Adding nullability annotations to it is also just nice.
And some improved formatting never hurts.
When receiving a `CancellationNotification`, we cancel the task that handles the request with that ID.
This will cause `cancel_notification` to be sent to sourcekitd or a `CancellationNotification` to be sent to `clangd`, which ultimately cancels the request.
rdar://117492860
Instead of just having barriers and non-barriers, this allows `AsyncQueue` to track dependencies between tasks at a more fine-grained level.
For example, we can now specify that requests that affect one document only depend on edits to that same document and are not blocked by edits to any other document. As a consequence, a busy `sourcekitd` will not block requests from `clangd` to be executed and vice versa.
Resolves#875
rdar://116705652
Each `sourcekitd` uses a single, global code completion session but we were managing code completion sessions on the `SwiftLanguageServer` level. This had two issues:
- Code completion is considered non-blocking on `SourceKitServer` and thus we could execute two concurrent code completion requests, which would conflict with each other.
- You could have multiple `SwiftLanguageServer`s that each have a connection to `sourcekitd` but share the same `sourcekitd` state. This shouldn't happen in the real world but does happen if we create multiple `SourceKitServer` instances in tests.
OSLog is the suggesting logging solution on Apple platforms and we should be using it there, taking advantage of the different log levels and privacy masking.
Switch sourcekit-lsp to use OSLog on Apple platforms and implement a logger that is API-compatible with OSLog for all uses in sourcekit-lsp and which can be used on non-Darwin platforms.
The goal of this commit is to introduce the new logging API. There are still improvements about what we log and we can display more privacy-insensitive information after masking. Those changes will be in follow-up commits.
