This fixes two issues:
1. The SwiftPM build system was setup without passing through whether it
should prepare or not. This meant that we lost eg. the argument to
allow compiler errors when building the AST (even though it was set
when building the modules)
2. The compiler argument adjustment to remove harmful and unnecessary
flags only applied to indexing arguments, not those passed to the AST
builds
Resolves rdar://141508656.
(cherry picked from commit ab12429651)
There were a few places that options only took place *after* determining
a build system, even though we have multiple that impact the search (eg.
`defaultBuildSystem` and `searchPaths`).
Additionally track project root and configuration paths separately, so
that when searching for implicit workspaces we can make sure to skip
creating duplicates.
(cherry picked from commit 0c896696c9)
If you have a package located at `/pkg` and a symlink at `/symlink` and you open `/symlink` as a workspace, the SwiftPMBuildSystem’s project root would be `/pkg`. This would mean that it also only knew about build settings for files in `/pkg`, not in `/symlink`. Thus, whenever we were opening a file in `/symlink` we would create an implicit workspace to handle it (but which ended up having a project root at `/symlink` again) – or something close to this.
We shouldn’t need to realpath here. If you open `/symlink`, we should view `/symlink` as the project root of your workspace.
(cherry picked from commit 8617b8bbcc)
This allows us to clean up the creation of `TestBuildSystem` a little bit because the tests can create `TestBuildSystem` instead of retrieving it from the `BuildSystemManager`.
rdar://142906050
(cherry picked from commit 31b1909ce1)
Currently, when there‘s a syntax error in a package manifest, we don’t get any build settings from it in SourceKit-LSP and thus loose almost all semantic functionality. If we can’t parse the package manifest, fall back to providing build settings by assuming it has the current Swift tools version.
Currently, when there‘s a syntax error in a package manifest, we don’t get any build settings from it in SourceKit-LSP and thus loose almost all semantic functionality. If we can’t parse the package manifest, fall back to providing build settings by assuming it has the current Swift tools version.
Fixes#1704
rdar://136423767
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.
The timers were racy and on Windows we would get the updated build targets / build settings before we expect them. Change the tests to explicitly tell the build server when to change the targets / settings it reports by sending it a `workspace/didChangeWatchedFiles` notification.
This should also speed up the tests because we don’t have a 1s timer anymore.
`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
I saw a nondeterministic test failure of `AsyncUtilsTests.testWithTimeoutEscalatesPriority` and I believe this was the cause.
Also refactor a few test helper functions on the way.
The original idea behind this test was that only opening `Crash.swift` would retrieve build settings for `Crash.swift`. But that wasn’t actually true: Scanning for tests also retrieved build settings (to get the test’s module name). This caused test failures if we set `SOURCEKIT_LSP_TEST_TIMEOUT: 10`, like we do in `settings.json`.
Improve the test to actually check that the BSP server has crashed and increase timeout to be bigger than the 10s restart delay.
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
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.
Xcode 16 with Swift 6 has been released, we can drop support for building and testing SourceKit-LSP using a Swift 5.10 toolchain. This allows us to remove a number of workarounds.
