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
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.
This wasn’t an issue when we were always waiting for an up-to-date build graph before indexing files but now we could still have an old build graph that contains the deleted files and thus start an indexing process for a file that doesn’t exist anymore on disk. And it’s cleaner anyway.
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.
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.
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.
