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
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.
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.
We were blocking the initialization response on `self.buildSystemManager.testFiles`, which requires the list of test files to be determined. Make that operation asynchronous so that a slow build server can’t take down all of SourceKit-LSP.
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.
