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
Running tests in parallel causes nondeterministic failures on Linux (rdar://92260631). Disable parallel testing on all platforms except Darwin until that issue has been fixed.
Add new flags '--cross-compile-host' and '--cross-compile-config' and use them to
cross-compile, gated only for Android for now. Add a '--prefix' flag to install
to a cross-compiled toolchain instead and set 'SWIFT_EXEC' when using SPM, so it
uses the right Swift toolchain.
