Commit Graph

10 Commits

Author SHA1 Message Date
Owen Voorhees
f04b971726 Adopt swift-tools-protocols 2025-10-31 14:11:11 -07:00
Alex Hoppen
95538e7de9 Migrate appendingPathComponent to appending(component:)
`appending(component:)` is the more modern API and can take multiple path components at the same time.
2025-09-23 16:57:56 +02:00
Alex Hoppen
a005021666 Support indexing of mulitple Swift files within the same compiler invocation
Fixes #1268
2025-09-20 16:26:26 +02:00
Alex Hoppen
d73433128d Make the build/logMessage conform to the BSP spec
When I added the log structure to `build/logMessage` in #2022 I must have assumed that the entire BSP notifciation was an extension defined by SourceKit-LSP and didn’t realized that this was actually a change that made the notification non-compliant with BSP. Change it up a little bit to make it compliant again.
2025-09-02 20:41:40 +02:00
Alex Hoppen
c31b62eeda Merge pull request #2259 from ahoppen/only-reload-current-package
Improve package reloading logic when manifest is changed
2025-08-25 23:26:25 +02:00
Alex Hoppen
ac0eb22226 Improve package reloading logic when manifest is changed
Two improvements to the logic that determines if we need to reload the package on a file change:
1. Only reload a package if the modified package manifest or Package.resolved is in the root of the package folder. This is relevant if we have a multi-root workspace, in which currently a single change to a package manifest or Package.resolved causes all packages to get reloaded.
2. While I was at it, I noticed that we didn’t properly handle version-specific package manifests. Also trigger a package reload if a version-specific package manifest is modified, created or deleted.
2025-08-25 09:23:08 +02:00
Alex Hoppen
13007e7493 Catch output-file-map.json write error thrown from TSC
We already had logic to retry loading a package manifest if writing the output-file-map failed. This only covered errors thrown from Foundation but I was seeing similar errors from TSC. Cover those as well.
2025-08-25 07:48:46 +02:00
Alex Hoppen
d811fcf855 Ensure that we end the Reloading package interval if a call in reloadPackageAssumingOnPackageLoadingQueue throws
If a call in `reloadPackageAssumingOnPackageLoadingQueue` throws, we weren’t getting to the end of it and would thus never end the signpost started within. Move the `endInterval` call up ensure it is always ended.

Found this while investigating https://ci-external.swift.org/job/swift-PR-windows/44247/console, which failed SourceKit-LSP testing because PackageA could not be loaded due to

```
Initial package loading: invalid access to C:\Users\swift-ci\jenkins\workspace\swift-PR-windows\build\tmp\lsp-test\924F7085\PackageA\.build\index-build\x86_64-unknown-windows-msvc\debug\MyLibrary.build\output-file-map.json
```
2025-08-13 13:37:37 +02:00
Alex Hoppen
98cd30bb1c Apply exhaustive swift-format configuration from swift-syntax
Apply the exhaustive swift-format configuration from https://github.com/swiftlang/swift-syntax/pull/3117 to sourcekit-lsp. Also apply all automatic formattings.
2025-08-11 09:23:39 +02:00
Alex Hoppen
7f4f92e5bd Rename build system to build server in most cases
The term *build system* predated our wide-spread adoption of BSP for communicating between SourceKit-LSP to the build system and was never really the correct term anyway – ie. a `JSONCompilationDatabaseBuildSystem` never really sounded right. We now have a correct term for the communication layer between SourceKit-LSP: A build server. Rename most occurrences of *build system* to *build server* to reflect this. There are unfortunately a couple lingering instances of *build system* that we can’t change, most notably: `fallbackBuildSystem` in the config file, the `workspace/waitForBuildSystemUpdates` BSP extension request and the `synchronize-for-build-system-updates` experimental feature.
2025-08-02 08:45:01 +02:00