`extractIndexedOccurences` mostly dealt with how to create a fallback value and we didn’t support fallback values in 3/4 cases. Remove it, simplifying the callers of `extractIndexedOccurances` along the way.
VS Code does not request diagnostics again for a document if the diagnostics request failed. Since sourcekit-lsp usually recovers from failures (e.g. after sourcekitd crashes), this is undesirable. Instead of returning an error, return empty results.
VS Code considers the position after an identifier as part of an identifier. Ie. if you have `let foo| = 1`, then it considers the cursor to be positioned at the identifier. This scenario is hit, when selecting an identifier by double-clicking it and then eg. performing jump-to-definition. In that case VS Code will send the position after the identifier.
`sourcekitd`, on the other hand, does not consider the position after the identifier as part of the identifier.
To bridge the gap here, normalize any positions inside, or directly after, an identifier to the identifier's start.
Fixes#820
rdar://115557453
SourceKit-LSP supports explicit cancellation and thus we don’t need to do the implicit cancellation of cursor info and related identifiers on subsequent requests.
Finetune the code
Finetune the code
Finetune the code
Update the code per comments
Use location marker instead of hard coded indexes
Update the test to align the code convention
Rename a variable
Correct unit tests
Format the code
Update Package.swift
The changes in #945 changed the dependencies but did not correct them in
the CMakeLists.txt resulting in a broken build. Resynchronise the
dependencies across Package.swift and CMake.
sourcekitd returns diagnostics with the first letter lowercase. Xcode, for example, shows the messages with the first letter uppercases. I think that looks nicer and we should also uppercase the first letter in sourcekit-lsp.
Previously, we would sometimes log errors for example for the `setTrace` notification sent by VS Code. To avoid those logs, add cases for all known requests and notifications to the `TaskMetadata` initializers.
When running sourcekit-lsp’s tests using Xcode 15, they fail because the sourcekitd in Xcode 15 does not contain the semantic tokens request. The intended workaround/fix is to dowload a recent Swift development snapshot from swift.org and set it as `SOURCEKIT_TOOLCHAIN_PATH` when running tests. But that’s not a great experience for new contributors. Instead, if sourcekitd doesn’t support the semantic tokens request, simply skip the test.
This also changes the implementation of the semantic tokens LSP request slightly: When the sourcekitd request to get semantic tokens fails, we now fail the entire LSP request, instead of returning the tokens from the synax tree. I think that’s reasonable because the editor did ask for semantic tokens, not syntactic tokens.
Fixes#940
rdar://117590581
Since asyncifying all the request handling, `Request` only had a few lingering uses. Remove most of them and shrink it down to a type that only contains the request’s parameters and the reply block of the corresponding type.
And while we’re doing this, also move `NotificationType.forLogging` out of the `LanguageServerProtocol` module to remove the dependency from `LanguageServerProtocol` on `LSPLogging`.
Resolves#881Resolves#936
rdar://116705662
rdar://117562587
When we couldn’t start a build server or find a SwiftPM package, we currently always create a `CompilationDatabaseBuildSystem`, even if no `compile_commands.json` or `compile_flags.txt` exits. Every request for build settings would then log an error that the compilation database can’t be opened, which was very spammy. Instead, if the compilation database can’t be loaded, just set the build system to `nil` and log a single error message.
It’s not entire clear why we have a fallback value if no document service can serve a request and I checked that VS Code behaves if we return empty results for jump to definition or if we return an error. To simplify the codebase, we should just throw an error here and remove the `fallback` parameter from `handleRequest`.
Resolves#862
rdar://116703662
