If a source file is part of multiple targets, we should index it in the context of all of those targets because the different targets may produce different USRs since they might use different build settings to interpret the file.
When the client supports it, communicate the structure of tasks that were stared during background indexing or by the build server to the client. If there are multiple operations happening in parallel, this allows the client to display them in separate log tracks instead of interspersing them with the emoji prefixes like we do today.
Indexing a header via a main file and indexing the main file itself are two different index tasks that update the `indexStoreUpToDateTracker` in different ways. We should thus consider them differently in `inProgressIndexTasks` as well.
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.
The closures aren’t guaranteed to be called on the same thread as the process was launched, which can cause assertion failure by the concurrency runtime.
rdar://142813605
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.
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
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.
Do one of the following for every `FIXME` or `TODO` comment
- Add an issue that tracks the task
- Remove the comment if we are not planning to address it
Change a l public declarations to the `package` access level, accept for:
- The `LanguageServerProtocol` module
- The `BuildServerProtocol` module
- `InProcessClient.InProcessSourceKitLSPClient`
- `LanguageServerProtocolJSONRPC` (I would like to create a more ergonomic API for this like `InProcessSourceKitLSPClient` in the future, but for now, we’ll leave it public)
Unfortunately, our pattern of marking functions as `@_spi(Testing) public` no longer works with the `package` access level because declarations at the `package` access level cannot be marked as SPI. I have decided to just mark these functions as `package`. Alternatives would be:
- Add an underscore to these functions, like we did for functions exposed for testing before the introduction of `SPI`
- Use `@testable` import in the test targets and mark the methods as `internal`
Resolves#1315
rdar://128295618
We were sending `SIGINT` to `swift-frontend` processes if they didn’t terminate after 2 minutes. However, `swift-frontend` doesn’t listen to `SIGINT`.
If a task running `waitUntilExitStoppingProcessOnTaskCancellation` is cancelled and the process doesn’t terminate on a `SIGINT` after 2 seconds, kill it.
rdar://130103147
Users should not need to rely on this request. The index should always be updated automatically in the background. Having to invoke this request manes there is a bug in SourceKit-LSP's automatic re-indexing. It does, however, offer a workaround to re-index files when such a bug occurs where otherwise there would be no workaround.
rdar://127476221
Resolves#1263
Since the `Atomic*` types can not be marked as `Sendable` (because they aren’t C structs), we can change the variables to constants and can remove `nonisolated(unsafe)`.
We used C atomics but these were allocated as Swift variables. Even thought they were atomic, concurrent accesses to them could violate Swift’s exclusivity laws, raising thread sanitizer errors.
Allocate the C atomics using malloc to fix this problem.
rdar://129170128
Unfortunately, `setpriority` only allows reduction of a process’s priority and doesn’t support priority elevation (unless you are a super user). I still think that it’s valuable to set the process’s priority based on the task priority when it is launched because many indexing processes never get their priority escalated and should thus run in the background.
On Windows, we can elevate the process’s priority.
rdar://127474245
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 also means that you can use the index log to view which tasks are currently being executed.
Since we only have a single log stream we can write to, I decided to prefix every line in the index log with two colored emojis that an easy visual association of every log line to the task that generated them.
I noticed that we were missing a bunch more arguments (in particular for clang index invocations), while diagnosing rdar://129071600, which is fixed by passing `-experimental-allow-module-with-compiler-errors` to the Swift index invocations.
rdar://129071600
Time out updating of the index store after 2 minutes. We don't expect any single file compilation to take longer than 2 minutes in practice, so this indicates that the compiler has entered some kind of loop. We will try indexing the file again when it is edited or when the project is re-opened.
rdar://128732571
