Technically, the watched files notification can change the response of any other request (eg. because a target needs to be re-prepared). But treating it as a `globalConfiguration` inserts a lot of barriers in request handling and significantly prevents parallelism. Since many editors batch file change notifications already, they might have delayed the file change notification even more, which is equivalent to handling the notification a little later inside SourceKit-LSP. Thus, treating it as `freestanding` should be acceptable.
Also, simplify the logic needed in tests to write modified files to disk because we now need to run a barrier request in tests to ensure that the watched file notification has been handled.
Sometimes file writes fail on Windows because another process (like sourcekitd or clangd) still has exclusive access to the file but releases it soon after. Retry to save the file if this happens. This matches what a user would do.
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.
These tests were designed to poll for the next diagnostic notification and if that notification didn’t contain the expected result, try again.
But if we didn’t get any diagnostic notification in 1s, we would unconditionally fail instead of trying again, which was not intended.
`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
We need to watch for changes to `Package.resolved` so that we can update the dependency checkouts in `.index-build` when the user runs `swift package update`.
Package manifests don’t have an associated target to prepare and are represented by a `ConfiguredTarget` with an empty target ID. We were mistakingly running `swift build` with an empty target name to prepare them, which failed. There is nothing to prepare.
`clangd` may return diagnostics from the old build settings sometimes (I believe when it's still building the preamble for shared.h when the new build settings come in). Check that it eventually returns the correct diagnostics and allow it to return outdated diagnostics for a short while.
Now that all the types that model test projects are suffixed `Project` instead of `Workspace`, the `ws` abbreviation doesn‘t make sense. It also never really fit with the new style of avoiding abbreviations. Rename all occurrences to `project`.
rdar://124727401
Rename all the classes that write files to disk to create a test project that we can open in sourcekit-lsp to end with `TestProject`. This is better than the old `Workspace` suffix because it avoids ambiguities with the `Workspace` type inside sourcekit-lsp.
- IndexedSingleSwiftFileWorkspace -> IndexedSingleSwiftFileTestProject
- MultiFileTestWorkspace -> MultiFileTestProject
- SwiftPMTestWorkspace -> SwiftPMTestProject
Currently, all tests send publish diagnostics notifications, which is noise in the logs for most tests. Change the tests to use the pull diagnostics model by default and make the push diagnostic model opt-in.
rdar://123241539
Add `.swift-format` to the repo and format the repo with `swift-format`.
This commit does not add any automation to enforce formatting of sourcekit-lsp in CI. The goal of this commit is to get the majority of source changes out of the way so that the diff of actually enforcing formatting will have fewer changes or conflicts.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
The asyncification changes caused some non-deterministic test failures. I believe that some of these are due to race conditions that are the result of the partial transition to actors.
Instead of merging the asyncification piece by piece, I will collect the changes asyncification changes in a branch and then qualify that branch througougly (running CI multiple times) before merging it into `main`.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
When running the test suite on Windows, these forced unwraps would fail.
Adopt `throws` on the cases and be more lenient of the failure as that
is reported as a test failure. This allows us to run the test suite to
completion even if it fails.
Instead of having ad-hoc timeout durations in all the test cases, specify a default timeout duration that can be used by tests.
This allows us increase the timeout duration for all tests if we discover that e.g. sourcekitd is slower in CI setups.
rdar://91615376
