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`.
If a build server copies files (eg. header) to the build directory during preparation and those copied files are referenced for semantic functionality, we would currently jump to the file in the build directory. Teach SourceKit-LSP about files that are copied during preparation and if we detect that we are jumping to such a file, jump to the original file instead.
So far only the definition request checks the copied file paths. Adding support for copied file paths in the other requests will be a follow-up change.
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
This request is generally useful, not only for tests within SourceKit-LSP but also:
- In editor tests that want to test the integration with SourceKit-LSP
- In code analysis tools that want to gather project information using SourceKit-LSP and need an up-to-date index for that.
Remove the experimental feature guard from `workspace/_synchronize`, consequently rename it to `workspace/synchronize` and only guard the `buildServerUpdates` option on the synchronize request by an experimental feature because its long-term usefulness is still not fully understood yet.
When the client supports it, communicate the structure of tasks that were stared during background indexing or by the build server to the client. If there are multiple operations happening in parallel, this allows the client to display them in separate log tracks instead of interspersing them with the emoji prefixes like we do today.
This can be useful to IDEs that want to perform some additional semantic processing of source files, which requires knowledge of a file’s build settings.
This request allows IDEs to disable SourceKit-LSP’s background indexing functionality when it requires all compute resources for other, more interactive, tasks.
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.
Gabe Braden
Alex Hoppen
Rintaro Ishizaki
Steffeeen
Owen Voorhees
Josh Arnold
lijunliang.9819
Ben Barham
Ben Barham
MahdiBM
Yuta Saito