The `WorkspaceConfiguration.default` was being used to populate
the `Workspace`; there was an extra step here needed to assure that
we are propagating the trait configuration to the workspace.
The added test assures that non-default traits that are enabled are
indeed processed as enabled.
Migrate remaining AtomicBool / AtomicUInt32 usages in test cases to
ThreadSafeBox / Atomic.
- Closure-captured `AtomicBool` flags become `ThreadSafeBox<Bool>` for
now. We will revisit this when eliminating ThreadSafeBox.
- One `AtomicUInt32` counter (SourceKitDRegistryTests.swift's
`nextToken`) to `Atomic<UInt32>`.
testToolsets: sourcekit-lsp is built against a just-built SwiftPM,
which can use macOS 10.13 as the minimum for packages with no explicit
platforms requirement. The preparation step runs the toolchain's
'swift build', which can use a higher macOS minimum deployment target.
The resulting module embeds a higher deployment target, causing a
spurious mismatch diagnostic when the other target imports it.
testBasicSwiftArgs (swiftbuild variant): swift-build can clamp the
deployment target to the SDK's MinimumDeploymentTarget, which can be
above the 10.13 the BSP reports, so the expected triple no longer
matches.
Fix by explicitly setting the deployment target to 13.0 in both test
packages via 'platforms: [.macOS(.v13)]'.
There was feedback in #2621 to update how the `.buildSystem_{config}`
file was be created. While looking as this change, I converted one test
to a parameterized and also ensure the `.buildSystem_{config}` file is
created in the `createFiles()` call.
Relates to #2621
SwiftPM PR #9985 introduce files in the scratch path whose contents
indicate which build system was used to build artifact for a given build
configuration. if this file exist, use it's contents to infer the build
system. Otherwise, fallback to the existing behaviour.
Fixes: #2576
The test was constructing the percent-encoded file URL from `filePath`,
which uses native OS path separators. On Windows this produced a
backslash-separated path inside a `file://` URL, making the URL
malformed. Fix by replacing `+` with `%2B` in `absoluteString` instead,
which is already a well-formed URL string with forward slashes on all
platforms.
rdar://175272642
Binary targets backed by remote `.artifactbundleindex` URLs cause
SwiftPM to re-extract the artifact bundle into the scratch directory
on every package load. The resulting file-change events (delete +
create) for the extracted files triggered another reload, causing an
infinite loop.
Add `isInScratchDirectory` to `fileEventShouldTriggerPackageReload`
to filter out events before the build-settings check. It covers
both the configured scratch directory and the default `.build/`
directory (which receives regular `swift build` output even when
a custom scratch path is configured).
Also add tests using local zip-based binary targets to cover both
the default and custom-scratch-path scenarios. Local zips are used
in the tests to avoid a network dependency; they exercise the same
`isInScratchDirectory` code path even though the infinite loop in
practice requires a remote `.artifactbundleindex` target (where
SwiftPM's checksum mismatch causes re-extraction on every load).
https://github.com/swiftlang/sourcekit-lsp/issues/2615
Currently, `testBasicSwiftArgs` fails if the user’s toolchain is not recent enough to have `swift package experimental-build-server`. Skip testing the SwiftPM BSP server integration in this case, similar to what we do in other tests using `SkipUnless`.
We previously waited for the initialization response from the build server during the creation of a `Workspace` so that we could create a `SemanticIndexManager` with the index store path etc. that was returned by the `build/initialize` response. This caused all functionality (including syntactic) of SourceKit-LSP to be blocked until the build server was initialized.
Change the computation of the `SemanticIndexManager` and related types to happen in the background so that we can provide functionality that doesn’t rely on the build server immediately.
Fixes#2304
When the BSP server fails to initialize, it can’t give us any compiler arguments and we won’t be able to provide semantic functionality. Show the message to the user so they can do something about fixing it instead having to dig into SourceKit-LSP logs.
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.
Bri Peticca
Rintaro Ishizaki
25harsh
Bassam Khouri
Alex Hoppen
Owen Voorhees
Ben Barham