I saw `testBackgroundIndexingHappensWithLowPriority` hang once. This should help us determine where we are hanging if we see the hang again.
rdar://143303256
I feel like the implementations are actually simpler if we split them. This will also allow us to add more advanced logic to the JSON compilation database build system in the future, such as inferring the toolchain from the compile command.
There were a few places that options only took place *after* determining
a build system, even though we have multiple that impact the search (eg.
`defaultBuildSystem` and `searchPaths`).
Additionally track project root and configuration paths separately, so
that when searching for implicit workspaces we can make sure to skip
creating duplicates.
This allows us to clean up the creation of `TestBuildSystem` a little bit because the tests can create `TestBuildSystem` instead of retrieving it from the `BuildSystemManager`.
rdar://142906050
If you have a package located at `/pkg` and a symlink at `/symlink` and you open `/symlink` as a workspace, the SwiftPMBuildSystem’s project root would be `/pkg`. This would mean that it also only knew about build settings for files in `/pkg`, not in `/symlink`. Thus, whenever we were opening a file in `/symlink` we would create an implicit workspace to handle it (but which ended up having a project root at `/symlink` again) – or something close to this.
We shouldn’t need to realpath here. If you open `/symlink`, we should view `/symlink` as the project root of your workspace.
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
`SourceFilesAndDirectoriesKey` contained all source files in the project and computing its hash value was pretty expensive. The key didn’t really provide any value here because the only way it changes is if the build targets change and if that’s the case, we already clear `cachedSourceFilesAndDirectories`, so we can just avoid the hash value computation.
Currently, when there‘s a syntax error in a package manifest, we don’t get any build settings from it in SourceKit-LSP and thus loose almost all semantic functionality. If we can’t parse the package manifest, fall back to providing build settings by assuming it has the current Swift tools version.
Currently, when there‘s a syntax error in a package manifest, we don’t get any build settings from it in SourceKit-LSP and thus loose almost all semantic functionality. If we can’t parse the package manifest, fall back to providing build settings by assuming it has the current Swift tools version.
Fixes#1704
rdar://136423767
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.
When we have background indexing enabled, SourceKit-LSP manages the dependencies. We should thus allow it to update them, eg. after `Package.resolved` was updated.
Some SwiftPM functions check whether their observability scope has errors. If we use the same observability scope for all SwiftPM operations during SourceKit-LSP’s lifetime, a single SwiftPM error will set the `hasError` bit in that observability scope for the entirety of SourceKit-LSP’s lifetime, impacting all upcoming SwiftPM operations.
Creating a separate child scope for every operation fixes
Adding an item to `AsyncQueue` was linear in the number of pending queue items, thus adding n items to an `AsyncQueue` before any can execute is in O(n^2). This decision was made intentionally because the primary use case for `AsyncQueue` was to track pending LSP requests, of which we don’t expect to have too many pending requests at any given time.
While we can't fix the quadratic performance issue in general, we can resolve the quadratic issue of `AsyncQueue<Serial>` by making a new task only depend on the last item in the queue, which then transitively depends on all the previous items. `AsyncQueue<Serial>` are the queues that are most likely to contain many items.
Fixes#1725
rdar://137886469
