When the compiler in `compile_commands.json` references a `swift` executable that’s a symlink to `swiftly`, SourceKit-LSP got confused because the `swift` executable doesn’t reside in a real toolchain, causing us to not provide any semantic functionality.
When we discover that the `swift` executable reference in compile commands references a `swiftly` executable, use `swiftly use -p` to resolve the binary in the real toolchain and continue operating based on that.
Fixes#2128
rdar://150301344
The SwiftPM smoke test still fails to build. I see the SwiftASN1
modules aren't getting added to the include path. Hopefully an
explicit dependency will fix that.
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 is only one real class that implements the `SourceKitD` protocol, so there really isn’t any need for the protocol + class split at all. Unify them to make code simpler to reason about.
When SourceKit-LSP is shut down, we should make sure that we don’t leave behind child processes, which will become orphans after SourceKit-LSP has terminated. What’s worse, when SourceKit-LSP has exited, these processes might not have any process to read their stdout/stderr, which can lead to them running indefinitely.
This change does not cover the termination of subprocess trees. For example, if we launch `swift build` and need to kill it because it doesn’t honor SIGINT, its child processes will still live on. Similarly, if we kill a BSP server, its child processes might live on. Fixing this is a drastically bigger endeavor, likely requiring changes to Foundation and/or TSC. I filed https://github.com/swiftlang/sourcekit-lsp/issues/2080 for it.
We would hit quadratic behavior in `AsyncQueue` when the build system floods us with `build/logMessage` or `build/task(Start|Progress|Finish)` notifications because we record a dependency on all of the pending log message handling tasks.
We can extend the improvement made in https://github.com/swiftlang/sourcekit-lsp/pull/1840 to fix this quadratic problem: If the current task depends on a task with metadata that depends on itself (ie. all tasks of metadata that needs to be executed in-order), we only need to depend on the last task with that metadata.
This covers many message types and we can now only get into quadratic behavior if we get flooded with two different kinds of messages: One that does not have a self-dependency and one that depends on the message without a self-dependency. In terms of LSP messages, this could be a document read followed by a document update, but I think this is a lot more unlikely than getting spammed with one type of message.
Otherwise, we would strip away the `-o`, leaving the command line without any output path option and thus not able to generate a unit file (which requires an output path).
If a source file is part of multiple targets, we should index it in the context of all of those targets because the different targets may produce different USRs since they might use different build settings to interpret the file.
We need a mapping from source file to its output path in order to support source files that are part of multiple targets (because we need the output path to check if we have an up-to-date unit for a file in a given target). To achieve this mapping, it’s easier to tag the output path for each source file onto the `buildTarget/sources` request.
Do not apply the standardized file normalization to the source file itself. Otherwise we would get the following behavior:
- We have a build system that uses standardized file paths and index a file as /tmp/test.c
- We are asking for the main files of /private/tmp/test.c
- Since indexstore-db uses realpath for everything, we find the unit for /tmp/test.c as a unit containing /private/tmp/test.c, which has /private/tmp/test.c as the main file.
- If we applied the path normalization, we would normalize /private/tmp/test.c to /tmp/test.c, thus reporting that /tmp/test.c is a main file containing /private/tmp/test.c,
But that doesn't make sense (it would, in fact cause us to treat /private/tmp/test.c as a header file that we should index using /tmp/test.c as a main file.
This allows us to more easily test behavior for build servers that have different behavior than SwiftPM and compile commands without having to implement the build server in Python.
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.
On Darwin platforms, this fixes the following problem: indexstore-db by itself returns realpaths but the build system might be using standardized Darwin paths (eg. realpath is `/private/tmp` but the standardized path is `/tmp`). Because of this, when inferring the main file for a file, we might get a URI that the build system doesn’t know about. To fix this, if the realpath that indexstore-db returns could not be found in the build system's source files but the standardized path is part of the source files, use the standardized path instead.
For each file in the changed targets, we still check whether it has an up-to-date unit based on timestamps. The important thing for this change is that we start indexing files for which we only receive build settings after an update from the build server.
This helps in the following situation: A build system takes 5s to return build settings for a file and we have 10 requests for those build settings coming in that time period. Once we get build settings, we get 10 calls to `resultReceivedAfterTimeout` in `buildSettings(for:in:language:fallbackAfterTimeout:)`, all for the same document.
But calling `fileBuildSettingsChanged` once is totally sufficient.
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 gives the injected build system more flexibility by being able to respond to all BSP messages instead of only those methods defined in `BuiltInBuildSystem`.
