Remove hand-written `init?(fromLSPDictionary:)` / `encodeToLSPAny()`
from LSPAnyCodable types, relying instead on the default implementations
backed by `LSPAnyEncoder`/`LSPAnyDecoder`
When this option is set to `true` the results for
`textDocument/semanticTokens` include semantic tokens for syntactic
highlighting obtained from swift-syntax. If this option is set to
`false` only the semantic tokens obtained from SourceKit are included.
This option defaults to `false`.
There's been a couple issue where it is clear from the log of the global
configuration that options are being set *somewhere*, but users then
have to go searching in all the paths we lookup (which is quite a few).
Log each config we read so it's easy to see where the options are coming
from.
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.
This should be a last stop-gap measure in case sourcekitd or clangd get stuck, don’t respond to any requests anymore and don’t honor cancellation either. In that case we can restore SourceKit-LSP behavior by killing them and using the crash recovery logic to restore functionality.
rdar://149492159
There were a few places that options only took place *after* determining
a build system, even though we have multiple that impact the search (eg.
`defaultBuildSystem` and `searchPaths`).
Additionally track project root and configuration paths separately, so
that when searching for implicit workspaces we can make sure to skip
creating duplicates.
Providing a JSON schema for the configuration file should improve the
developer experience thanks to better auto-completion and diagnostics
support provided by some editors.
Additionally, we have been manually maintaining the configuration file
format documentation in `Documentation/Configuration File.md`, but it's
easy for the documentation to get out of sync with the actual schema.
This change introduces a new tool, `ConfigSchemaGen`, that generates a
JSON schema and a Markdown document for the configuration file based on
the Swift type definitions in the `SKOptions` module by using
swift-syntax.
This allows us to record the communication between SourceKit-LSP and the editor on a very low level to inspect any transfer issues. It also allows us to record an entire SourceKit-LSP session and replay it using
```
cat /path/to/mirror.log - | path/to/sourcekit-lsp
```
When we receive build settings after hitting the timeout, we call `fileBuildSettingsChanged` on the delegate, which should cause the document to get re-opened in sourcekitd and diagnostics to get refreshed.
rdar://136332685
Fixes#1693
Even if we don’t want to log any sensitive information, we can still log the keys of JSON objects and insensitive values such as integers and booleans.
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`
- `cancelTextDocumentRequestsOnEditAndClose`
We had the custom decoder function so that the keys weren’t required in the JSON but we could access eg. `SwiftPMOptions` without needing to deal with optionals in the codebase.
Make the accesses to these nested options structs a little more verbose but eliminate the source of the above bug, which seems like a good tradeoff.
As a user makes an edit to a file, these requests are most likely no longer relevant. It also makes sure that a long-running sourcekitd request can't block the entire language server if the client does not cancel all requests. For example, consider the following sequence of requests:
- `textDocument/semanticTokens/full` for document A
- `textDocument/didChange` for document A
- `textDocument/formatting` for document A
If the editor is not cancelling the semantic tokens request on edit (like VS Code does), then the `didChange` notification is blocked on the semantic tokens request finishing. Hence, we also can't run the `textDocument/formatting` request. Cancelling the semantic tokens on the edit fixes the issue.
rdar://133987424
Gabe Braden
Alex Hoppen
Rintaro Ishizaki
Steffeeen
Owen Voorhees
Josh Arnold
lijunliang.9819
Ben Barham
Yuta Saito