User-installed package headers are installed to `/usr/local/include` on
FreeBSD. The build system should tell the compiler where the additional
headers are located.
We have seen a few infinite spins in SourceKit-LSP testing recently. We should fix those spins but as a last stop-gap measure, introduce a timeout to all subprocess invocations, which will at least give us a failure instead of infinite waiting.
This adds a sourcekitd plugin that drives the code completion requests. It also includes a `CompletionScoring` module that’s used to rank code completion results based on their contextual match, allowing us to show more relevant code completion results at the top.
Instead of building SourceKit-LSP using SwiftPM's multi-arch xcbuild backend, build it for only one arch at a time and then run `lipo` to merge the two resulting binaries.
This should allow us to share build products between building installing and testing and also eliminates other quirks resulting from the xcbuild backend.
This improves serial test execution time of eg. `DocumentTestDiscoveryTests` from 36s to 22s because we don’t need to re-build the XCTest module from its interface when using an open source toolchain.
This also uncovered that we weren‘t passing the build setup flags to the prepare command.
rdar://126493151
For some reason the log message that we’re re-running tests in serial always showed up after the serial run in the build log output. Test if flushing stdout fixes the issue.
`swift test --parallel --verbose` prints the entire log output. We were assuming that it did not and re-run `sourcekit-lsp` tests in serial with log output if the parallel test run failed.
Suppress `--verbose` on `swift test`. This will cause it to not log any stderr logging output when running in parallel and log all stderr logging output when running in serial.
- Don’t explicitly add rpaths to `/usr/lib/swift`, `@executable_path/../lib/swift/macosx` and `@executable_path/../lib/swift-5.5/macosx` on Darwin. I don’t know what they were needed for but they don’t seem to be necessary. Also standard Swift command line tools created from Xcode don’t contain these rpaths.
rdar://121400644
'swift test' doesn't print os_log output to the command line. Use the `NonDarwinLogger` that prints to stderr so we can view the log output in CI test runs.
The parallel test logs are just so hard to read that they don’t really provide any value. Locally, running the tests in serial only increases test times by 1 minute, which I think is a tradeoff worth making to actually be able to tell what’s going wrong in CI.
sourcekit-lsp builds all the targets and there shouldn’t be any need to build `LSPBindings` and `_SourceKitLSP`. In fact, we can’t even build them if they are automatic targets.
Building SourceKitLSPPackageTests with cross-compilation enabled fails with
```
error: Could not find target named 'mypackagePackageTests_586B622B321A3B86_PackageProduct'
error: fatalError
```
For testing, we work around this by disabling cross-compilation. This is not possible for building, so we need to explicitly build all products.
When we build SourceKit-LSP in a unified SwiftPM workspace, a simple `swift build` invocation will build all products in the unified workspace (not just SourceKit-LSP products).
Currently, when building an open source toolchain, SourceKit-LSP is only built for x86_64. Copy the necessary cross-compilation parts from SwiftPM’s build script to also produce a fat sourcekit-lsp executable for both x86_64 and arm64.
rdar://78039145
