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.
For each file in the changed targets, we still check whether it has an up-to-date unit based on timestamps. The important thing for this change is that we start indexing files for which we only receive build settings after an update from the build server.
This helps in the following situation: A build system takes 5s to return build settings for a file and we have 10 requests for those build settings coming in that time period. Once we get build settings, we get 10 calls to `resultReceivedAfterTimeout` in `buildSettings(for:in:language:fallbackAfterTimeout:)`, all for the same document.
But calling `fileBuildSettingsChanged` once is totally sufficient.
This can be useful to IDEs that want to perform some additional semantic processing of source files, which requires knowledge of a file’s build settings.
This gives the injected build system more flexibility by being able to respond to all BSP messages instead of only those methods defined in `BuiltInBuildSystem`.
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.
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.
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.
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.
