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
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
We were calling `server.handle(notification:)`, which called directly into `SourceKitLSPServer` but request handling is implemented in `QueueBasedMessageHandler.handle(_:)`. Call that to ensure that we actually cancel requests after the test timeout.
`TestSourceKitLSPClient.handle` created a new `Task`. This means that we could swap the order of notifications received from SourceKit-LSP. In most cases this doesn’t matter but `BackgroundIndexingTests.testProduceIndexLogWithTaskID` checks that the notification to start a structured log is received before the first report, which might not be the case because of the `Task` here.
Change `PendingNotifications` to a class with a `ThreadSafeBox` to remove the need for a `Task`.
rdar://147814254
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.
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.
Depending on the system, mtime resolution might not be perfectly accurate. Particularly containers appear to have imprecise mtimes.
Wait a short time period before writing the new file to avoid situations like the following:
- We index a source file and the unit receives a time stamp and wait for indexing to finish
- We modify the source file but so quickly after the unit has been modified that the updated source file
receives the same mtime as the unit file
- We now assume that the we have an up-to-date index for this source file even though we do not.
Waiting 10ms appears to be enough to avoid this situation on the systems we care about.
rdar://147811044
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.
The XCTest and Testing version information is encoded into the
`PlatformInfo.plist` that is at the root of the platform. Use this to
determine the path for XCTest. This allows us to migrate the XCTest
location into an appropriate versioned directory.
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.
Skip formatting tests if the `swift-format` executable in the host toolchain doesn’t support `-` to indicate that it’s reading the source file from stdin
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.
Technically, the watched files notification can change the response of any other request (eg. because a target needs to be re-prepared). But treating it as a `globalConfiguration` inserts a lot of barriers in request handling and significantly prevents parallelism. Since many editors batch file change notifications already, they might have delayed the file change notification even more, which is equivalent to handling the notification a little later inside SourceKit-LSP. Thus, treating it as `freestanding` should be acceptable.
Also, simplify the logic needed in tests to write modified files to disk because we now need to run a barrier request in tests to ensure that the watched file notification has been handled.
