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.
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.
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
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.
The motivating change for this was to deterministically pick a main file for a header file instead of picking the first element in a set, which is not deterministic.
While doing this, I also changed the main file computation to not carry any state about previous main files around. If a header file is associated with a main file b.cpp and a new a.cpp gets added that imports the header as well, we should be using a.cpp for the build settings. That way we will get the same build settings if we close and re-open the project.
And this was a good opportunity to refactor some of the main file handling into smaller, more dedicated functions.
This generally seems like the cleaner design because `SourceKitServer` is actually able to semantically inspect the message and decide whether it can be handled concurrently with other requests.
The core idea here is that the toolchain language servers always call into `BuildSystemManager` and `BuildSystemManager` will always reply with build settings. If it hasn’t computed them yet, it will reply with fallback settings.
With that assumption, we can remove the `documentToPendingQueue` from `SourceKitServer` since there are no longer any documents that are pending – everything has a build settings immediately.
Similarly, `BuildSystemManager.mainFileStatuses` also isn’t needed anymore.
And lastly, since we know that `BuildSystemManager.buildSettings` will always return a value `registerForChangeNotifications` is changed not call `fileBuildSettingsChanged` immediately. Instead, it will only cause `fileBuildSettingsChanged` to be called when the file’s build settings change after the `registerForChangeNotifications` call.
This defines away an entire class of data races if delegate callbacks are delivered out-of-order. If we aren’t providing the new build settings in the delegate callback, then it doesn’t matter if two `fileBuildSettingsChanged` calls change order since they don’t carry any state.
