… `DocumentURI(for:testName:)`

…o-an-initializer

…o-an-initializer

…project

There are still a few tests left that explicitly check the before and after build state, which I didn’t modify.

rdar://128697501

…ditToDependency`

The closure that handled the `DiagnosticsRefreshRequest` was retaining `project`, which constituted a retain cycle.

…-documenturi-for-to-an-initializer

Change static method `DocumentURI.for(_:testName:)` to an initializer `DocumentURI.init(for:testName:)`

…n’t support background indexing

If the user has enabled background indexing in sourcekit-lsp but opens a project that doesn’t support background indexing (compilation database, build server), we should show a message after opening the workspace, informing the user that background indexing is only supported in SwiftPM projects at the moment.

Fixes swiftlang#1255
rdar://127474711

…s-1322-1329

Address review comments from swiftlang#1322 and swiftlang#1329

…ng-not-supported-message

Show message if background indexing is enabled but the workspace doesn’t support background indexing

…ndle

Eg. if the crash contained `-fmodule-map-file=/path/to/module.modulemap`, we weren’t including `/path/to/module.modulemap` in the diagnose bundle.

…ssary

…hain`

This allows us to inspect the Swift version and fix up compiler arguments from SwiftPM to account for an older version of SwiftPM being invoked using `swift build` than the one that’s bundled in-process with SourceKit-LSP.

When we detect that we’re running using a 5.10 toolchain, adjust the compiler arguments that we received from SwiftPM to drop any `/Modules` suffixes in the build directory, to account for the fact that 5.10 stores the modules one directory higher up (swiftlang/swift-package-manager#7103).

…ication-wherever-necessary

Rename `note` to `notification` throughout the codebase wherever necessary

Depending on whether clangd has finished indexing/built an AST/something, we get different code completion results. The actual integration test is only checking that we have a result with `insertText` `clib_func`, which is satisfied independently of whether clangd’s progress. Adopt the same assertion in this test case.

…rectory

Support running tests that require building with a Swift 5.10 toolchain

Relax assertion around `testIntegrationTest`

Fix a negation issue in the type of log message sent to the index log

…und-indexing

Switch most tests to use background indexing instead of building the project

…bundle

Add paths from compiler arguments spelled with `=` to the diagnose bundle

…nation

The change is introduced by swiftlang/swift-package-manager#7593

We are no longer skipping these tests, which means that we need to make them account for different error messages emitted by Swift 5.10.

I added warnings behind `#if compiler(>=6.1)` to give us a reminder that we can remove these checks when we no longer support running SourceKit-LSP with SwiftPM from Swift 5.10. Swift 6.1 doesn’t have to be this cut-off point but it’s the most likely candidate for now if we want to support the current and last Swift version from tip SourceKit-LSP.

…rn diagnostics from old build settings

`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.

[SwiftPMBuildSystem] Adjust `BuildParameters` use to indicate a desti…

I am seeing more preparation tasks going on than I expect. This should help us figure out why targets are being marked as out-of-date.

This exposes an issue where we wouldn’t rename a symbol on the clang side f a symbol was only defined in a header and not a C/C++/... file. In that case we failed to determine the language of the header file because there was no unit file that contained the header file. The cleaner solution here is to ask for the symbol provider of each occurrence directly.

rdar://127391127

…eature

Make passing `--experimental-prepare-for-indexing` to `swift build` an experimental feature

Instead of sending a message to the index log when an indexing task finishes, stream results as they come in

Add tests to rename C++ symbols exposed to Swift

Just two cases where we were logging an error that wasn’t strictly necessary and was just spamming the log at the high log levels.

This allows us to share common Swift utility functions between SourceKit-LSP and LSPLogging.

…diag-from-cache

Don’t cancel in-progress diagnostic generation when calling `DiagnosticReportManager.removeItemsFromCache`

Fallback build settings don’t even have an indexstore path set, so we would never pick up any index data generated from them. Also, indexing with fallback args has some other problems:
- If it did generate a unit file, we would consider the file’s index up-to-date even if the compiler arguments change, which basically means that we wouldn’t get any up-to-date-index even when we do get build settings for the file.
- It’s unlikely that the index from a single file with fallback arguments will be very useful as it can’t tie into the rest of the project.

This is only used so we don't log an error when receiving a `CancelRequestNotification` for a request that has just returned a response.

…some reason

Not sure if this ever happens but if it does, we should log it. Also, just start waiting again for another 10 years.

Create a `SwiftUtilities` module

Don’t index files with fallback build settings

Demote two log messages issued on the `error` level

Turns out that also most of the `withLock` definitions were never used.

…IfDiagnosticRequestIsCancelled`

I saw a few non-deterministic test failures. I think the issue was that handling of the `CancelRequestNotification` is done asynchronously, which left a short window in which the sourcekitd diagnostics request could run and return results instead of being cancelled. Wait for the diagnostic request to actually be cancelled before running it for real.

While doing this, also introduce proper sourcekitd test hooks instead of relying on the preparation test hooks, which just got run as a side effect.

…-propagate

Wait for cancellation to propagate in `testDontReturnEmptyDiagnosticsIfDiagnosticRequestIsCancelled`

Unify `withLock` implementations

…d-requests

Keep track of recently finished requests

Log when the 10 year wait that’s parking the main thread expires for some reason

Add some more overview documentation documents