We made quite a few fixes recently to make sure that path handling works correctly using `URL` on Windows. Use `URL` in most places to have a single type that represents file paths instead of sometimes using `AbsolutePath`.
While doing so, also remove usages of `TSCBasic.FileSystem` an `InMemoryFileSystem`. The pattern of using `InMemoryFileSystem` for tests was never consistently used and it was a little confusing that some types took a `FileSystem` parameter while other always assumed to work on the local file system.
`URL.path` returns forward slashes in the path on Windows (https://github.com/swiftlang/swift-foundation/issues/973) where we expect backslashes. Work around that by defining our own `filePath` property that is backed by `withUnsafeFileSystemRepresentation`, which produces backslashes.
rdar://137963660
When we receive build settings after hitting the timeout, we call `fileBuildSettingsChanged` on the delegate, which should cause the document to get re-opened in sourcekitd and diagnostics to get refreshed.
rdar://136332685
Fixes#1693
The build server is automatically shut down using a background task when `BuildSystemManager` is deallocated.
This, however, leads to possible race conditions where the shutdown task might not finish before the test is done, which could result in the connection being reported as a leak. To avoid this problem, we want to explicitly shut, down the build server when the `SourceKitLSPServer` gets shut down.
When we receive build settings after hitting the timeout, we call `fileBuildSettingsChanged` on the delegate, which should cause the document to get re-opened in sourcekitd and diagnostics to get refreshed.
rdar://136332685
If a BSP server crashes, we should try to relaunch it. Use a similar relaunch logic as the one we use for `clangd`: Try restarting immediately unless the BSP server has crashed within the last 30 seconds, in which case we delay the restart by 10s.
rdar://136311009
Fixes#1686
The interaction to an out-of-process BSP server still went through the `BuildServerBuildSystem`, which doesn’t forward all messages to the build system and uses the old push-based model for build settings.
If we discover that the BSP server supports the new pull-based build settings model, we now forward all methods to it directly, without going through `BuiltInBuildSystemAdapter`, which has been renamed to `LegacyBuildServerBuildSystem`.
rdar://136106323
rdar://127606323
rdar://126493405
Fixes#1226Fixes#1173
We currently allow sending requests to the BSP server before `build/initialize` returns. This is not valid in general and we should wait for the initialize result before sending any other messages.
rdar://136111469
When you had a package at `/pkg_real` and a symlink `/pkg` pointing to `/pkg_real`, then opened a workspace at `/pkg`, we wouldn’t get any build settings for any of the files. This was masked in tests because they still called `SwiftPMBuildSystem.targets(for:)`, which handled symlink resolution but wasn’t called in production.
Handle symlink resolution `BuildSystemManager`, remove `SwiftPMBuildSystem.targets(for:)` and its related members/methods, and migrate the tests to go through `BuildSystemManager`, which is what production code does. A nice side effect of this is that the tests will log the requests sent to the build system.
We had a retain cycle from `BuildSystemManager` to `LocalConnection`. Fix it by making `LocalConnection` have a weak reference to `BuildSystemManager`.
`buildTarget/inverseSources` is not required to be implemented by BSP servers and we have almost all information needed for it in `BuildSystemManager`.
This also makes sure that `buildTarget/sources` and `buildTarget/inverseSources` actually match each other. Before this change, we had source files like `Package.swift` for which we returned a target from `buildTarget/inverseSources` but that weren’t part of that target’s sources retrieved using `buildTarget/sources`.
