There was a very brief time when a `QueuedTask` would start executing but `isExecuting` was still sent to `false`. This caused the `preparationTask.isExecuting` check in `SemanticIndexManager.prepare` to fail after we did start preparation, causing the preparation of `LibB` in `testDontStackTargetPreparationForEditorFunctionality` to be cancelled, which wasn’t intended. Thus, the expected preparation tracker got out of sync and the test would fail.
rdar://136570212
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.
`buildTarget/inverseSources` is not required to be implemented by BSP servers and we have almost all information needed for it in `BuildSystemManager`.
This also makes sure that `buildTarget/sources` and `buildTarget/inverseSources` actually match each other. Before this change, we had source files like `Package.swift` for which we returned a target from `buildTarget/inverseSources` but that weren’t part of that target’s sources retrieved using `buildTarget/sources`.
We currently load the entire package before generating a `SwiftPMBuildSystem`. That means that the initialize request to SourceKit-LSP is blocked until the package has been loaded, preventing us from offering any sort of functionality, including syntactic functionality like formatting.
Decouple build system creation and build graph generation (aka. package loading for SwiftPM). We can operate with fallback build settings until the build graph has been loaded and reopen the document once the proper build settings are available.
rdar://126644596
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
The purpose of the different modules wasn’t clearly defined, which lead to inconsistent responsibilities between the different modules. Define each module’s purpose and move a few files between modules to satisfy these definitions.
There are a few more larger changes that will need to be made for a fully consistent module structure. These are FIXMEs in the new Modules.md document and I’ll address them in follow-up PRs.
If calls from `Debouncer` were scheduled every 0.5s but the debounce duration was 1s, we would always schedule the pending task and schedule a new one, never actually committing one. Debounce at most the debounce duration from the initially scheduled call.
The old implementation of inspecting the `InProgressPrepareForEditorTask` has a few race conditions including the fact that we would start the preparation task before the `inProgressPrepareForEditorTask` was set.
Instead, keep track of the purpose for each preparation task. This ends up simplifying the code as well.
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 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
