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.
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.
Add `.swift-format` to the repo and format the repo with `swift-format`.
This commit does not add any automation to enforce formatting of sourcekit-lsp in CI. The goal of this commit is to get the majority of source changes out of the way so that the diff of actually enforcing formatting will have fewer changes or conflicts.
Without this overload, `T` was inferred to be `Something?`, thus the first parameter was inferred to be `Something??` and the first parameter was always wrapped in an optional, effectively making `if let optional` never be hit.
The asyncification changes caused some non-deterministic test failures. I believe that some of these are due to race conditions that are the result of the partial transition to actors.
Instead of merging the asyncification piece by piece, I will collect the changes asyncification changes in a branch and then qualify that branch througougly (running CI multiple times) before merging it into `main`.
I noticed that the initial package loading can take ~5s. It’s good behavior to inform the client that sourcekit-lsp is busy reloading the package, showing the user that semantic functionality might not be ready yet.
https://github.com/apple/sourcekit-lsp/issues/620
rdar://112498447
I noticed that the initial package loading can take ~5s. It’s good behavior to inform the client that sourcekit-lsp is busy reloading the package, showing the user that semantic functionality might not be ready yet.
https://github.com/apple/sourcekit-lsp/issues/620
rdar://111917300
Explicitly import interfaces from TSCBasic which now allows us to
identify all the swift-tools-support-core interfaces which are in
use in SourceKit-LSP.
This allows sourcekit-lsp to make use of the path remappings recently added to
the index store and IndexStoreDB to remap remote paths into local paths
when loading index data locally.
These remappings can be provided via the `-index-prefix-map` command line flag to sourcekit-lsp or via the `BuildSystem` integration point.
When we introduce multiple workspaces, they need to share the same DocumentManager so we don’t accidentally open a Swift file twice in two workspaces that share the same `SwiftLanguageService`. Thus, `SourceKitServer` needs to start owning the document manager.
When we introduce multiple workspaces, they need to share the same DocumentManager so we don’t accidentally open a Swift file twice in two workspaces that share the same `SwiftLanguageService`. Thus, `SourceKitServer` needs to start owning the document manager.
This explicitly identifies the TSCUtility interfaces that SourceKit
depends on. This helps identify a "burn down list" of interfaces that
remain in TSC(Utility) which are in use. As these interfaces are
replaced, we can easily monitor the remaining interfaces that are in
use.
Using dynamic registration (when supported by the client) allows
us to provide different completion options for ObjC and Swift
files.
We should be able to expand this to other capabilities in the future
(e.g. semantic highlighting, execute command support).
