Otherwise we can get a situation where a `.swift` file is removed from swift-syntax, its `.o` file is still in the build directory because the build folder wasn't cleaned and thus we would link against the stale `.o` file.
rdar://142666044
VS Code spells file paths with a lowercase drive letter, while the rest of Windows APIs use an uppercase drive letter. Normalize the drive letter spelling to be uppercase.
Fixes#1855
rdar://141001203
Consider the following scenario: A project has target A containing A.swift an target B containing B.swift. B.swift is a symlink to A.swift. When A.swift is modified, both the dependencies of A and B need to be marked as having an out-of-date preparation status, not just A.
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.
https://github.com/swiftlang/sourcekit-lsp/pull/1714 changed the background preparation mode to `enabled` but a Swift 5.10 toolchain does not support `--experimental-prepare-for-indexing`. Thus, these tests fail. Skip tests that rely on background indexing when testing SourceKit-LSP with a Swift 5.10 host toolchain.
When `TestSourceKitLSPClient.nextNotification` timed out, it would cancel `AsyncSequence.Iterator.next()` and thus also cancel the underlying `AsyncStream` (which I only now found out). This means that calling `nextNotification` again would never return any notification. Hence, if we didn’t receive a `PublishDiagnosticsNotification` within the first timeout, we would never get one.
In some situations, we could return the timeout error from the timeout task, but receive a notification from the `self.notifications` `AsyncStream`. That notification would then be dropped and never get delivered to the test case, which can cause test cases to fail.
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
Currently, we return a `methodNotFound` error when we get a diagnostic refresh request from SourceKit-LSP. This doesn’t do any harm but draws the attention when reading test logs, despite being the expected result. Clean up that output by returning a proper response.
The goal for now is to get to a state where Windows tests are passing. Once we have that, we can start enabling tests again as we fix their unerlying issues.
Otherwise, the body task might finish before we yield the `TimeoutError` and thus `withTimeout` would not actually throw a `TimeoutError`.
rdar://137171114
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.
