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
- **Issue**: Since https://github.com/swiftlang/sourcekit-lsp/pull/1973, we are watching for all changes in SourceKit-LSP. This means that we get notified every time the index database is changed. Each of these modifications triggers a new task that waits for build system updates to determine if the modified file needs to be re-indexed. While this task finishes very quickly, it still causes `Scheduling indexing` to replace the `Indexing x / y` in the index status during initial indexing, which looks very noisy.
- **Explanation**: To avoid this flickering, only show `Scheduling indexing` in the index status if we aren’t already indexing any files
- **Scope**: Index progress status
- **Original PR**: This is a significantly reduced version of https://github.com/swiftlang/sourcekit-lsp/pull/2051
- **Risk**: Low, this only changes the precedence of status messages in the indexing status
- **Testing**: Manually verified that we don’t see `Scheduling indexing` appear during initial indexing of a package
- **Reviewer**: @bnbarham
Loading the build description sometimes fails non-deterministically on Windows because it's unable to write `output-file-map.json`, probably due to https://github.com/swiftlang/swift-package-manager/issues/8038.
If this happens, retry loading the build description up to 5 times.
This *shouldn't* be needed, but allows running plugins to be skipped if
there's any unexpected interactions with background indexing.
(cherry picked from commit a5343852c6)
We previously skipped building/running tool plugins here, which meant
that the compiler arguments for a target also missed any generated
sources. Use the new `BuildDescription.load` API from SwiftPM to address
this.
Resolves rdar://102242345.
(cherry picked from commit f525da52529bcc8c3e51985d99f72ae44725de70)
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.
(cherry picked from commit ab12429651)
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.
(cherry picked from commit 0c896696c9)
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.
(cherry picked from commit 8617b8bbcc)
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
(cherry picked from commit 31b1909ce1)
It is important that we cache this because we might find a lot of symbols in the same container for eg. workspace symbols (eg. consider many symbols in the same C++ namespace). If we didn't cache this value, then we would need to perform a `primaryDefinitionOrDeclarationOccurrence` lookup for all of these containers, which is expensive.
For example, searching for `only` in SourceKit-LSP’s codebase used to not return results in more than 20s (after which I gave up) and now returns >8000 results in <2s.
rdar://141412138
`inProgressTextDocumentRequests` is supposed to only be accessed on `textDocumentTrackingQueue` but we were accessing it outside of that queue. Because of this, we might try to remove requests from `inProgressTextDocumentRequests` before adding them, which would cause them to stay in the list indefinitely.
