- New `swift.play` CodeLens support that is an experimental feature while [swift play](https://github.com/apple/swift-play-experimental/) is still experimental
- Add #Playground macro visitor to parse the macro expansions
- File must `import Playgrounds` to record the macro expansion
- The `swift-play` binary must exist in the toolchain to
- TextDocumentPlayground will record the id and optionally label to match detail you get from
```
$ swift play --list
Building for debugging...
Found 1 Playground
* Fibonacci/Fibonacci.swift:23 "Fibonacci"
```
- Add LSP extension documentation for designing pending `workspace/playground` request
- Add new parsing test cases
- Update CMake files
Issue: #2339#2343
Add column to unnamed label
Update Sources/SwiftLanguageService/SwiftCodeLensScanner.swift
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Update Sources/SwiftLanguageService/SwiftPlaygroundsScanner.swift
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Update Sources/SwiftLanguageService/SwiftPlaygroundsScanner.swift
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Update Tests/SourceKitLSPTests/CodeLensTests.swift
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Address review comments
Fix test failures
Fix more review comments
Update for swift-tools-core
This allows us to easily get rid of some `@_inheritActorContext`. The others seem to be a little more tricky and I haven’t spent too much time at trying to figure out how to remove the attribute from those.
We should not take the number of files in an `UpdateIndexStoreTaskDescription` as an indication on how important the task is. If we do need this functionality, eg. because we want to update the index of files with syntactic matches for a rename term, this should be communicated using a specific purpose similar to `TargetPreparationPurpose`. Since the only reason we update the index store for a file right now is background indexing, such a check is not needed.
`ideApi` is only available within the plugin itself, it's not available
to sourcekitd. Switch to sending a completion request and checking
that we get full documentation back.
I suspect that we don’t wait for `TestSourceKitLSPClient` to finish deinitializing (and thus waiting for the shutdown response) when we destroy it in `tearDown` based on the logs in https://ci.swift.org/job/oss-swift-incremental-RA-macos-apple-silicon/9004 (rdar://160344405).
Since I generally dislike the `setUp` and `tearDown` methods and we have `CustomBuildServerTestProject` now to model a setup of a SourceKitLSP server with a custom build server, use that instead of manually hooking up the build server through a workspace.
When resolving documentation for code completion items, we fetch full
documentation through the newly added
`swiftide_completion_item_get_doc_full_copy` SourceKitD function, if not
found we fallback to brief documentation as before using
`swiftide_completion_item_get_doc_brief`.
> [!NOTE]
> Unlike brief documentation, SourceKitD doesn't cache full
documentation for completion results to avoid bloating memory with a lot
of large strings.
>
> As of now, SourceKit-LSP doesn't cache completion item documentation
either, should we introduce a new full documentation cache (e.g. using
`LRUCache`)?
If a build server copies files (eg. header) to the build directory during preparation and those copied files are referenced for semantic functionality, we would currently jump to the file in the build directory. Teach SourceKit-LSP about files that are copied during preparation and if we detect that we are jumping to such a file, jump to the original file instead.
So far only the definition request checks the copied file paths. Adding support for copied file paths in the other requests will be a follow-up change.
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.
When the compiler in `compile_commands.json` references a `swift` executable that’s a symlink to `swiftly`, SourceKit-LSP got confused because the `swift` executable doesn’t reside in a real toolchain, causing us to not provide any semantic functionality.
When we discover that the `swift` executable reference in compile commands references a `swiftly` executable, use `swiftly use -p` to resolve the binary in the real toolchain and continue operating based on that.
Fixes#2128
rdar://150301344
This should be a last stop-gap measure in case sourcekitd or clangd get stuck, don’t respond to any requests anymore and don’t honor cancellation either. In that case we can restore SourceKit-LSP behavior by killing them and using the crash recovery logic to restore functionality.
rdar://149492159
We were calling `server.handle(notification:)`, which called directly into `SourceKitLSPServer` but request handling is implemented in `QueueBasedMessageHandler.handle(_:)`. Call that to ensure that we actually cancel requests after the test timeout.
`TestSourceKitLSPClient.handle` created a new `Task`. This means that we could swap the order of notifications received from SourceKit-LSP. In most cases this doesn’t matter but `BackgroundIndexingTests.testProduceIndexLogWithTaskID` checks that the notification to start a structured log is received before the first report, which might not be the case because of the `Task` here.
Change `PendingNotifications` to a class with a `ThreadSafeBox` to remove the need for a `Task`.
rdar://147814254
There is only one real class that implements the `SourceKitD` protocol, so there really isn’t any need for the protocol + class split at all. Unify them to make code simpler to reason about.
This request is generally useful, not only for tests within SourceKit-LSP but also:
- In editor tests that want to test the integration with SourceKit-LSP
- In code analysis tools that want to gather project information using SourceKit-LSP and need an up-to-date index for that.
Remove the experimental feature guard from `workspace/_synchronize`, consequently rename it to `workspace/synchronize` and only guard the `buildServerUpdates` option on the synchronize request by an experimental feature because its long-term usefulness is still not fully understood yet.
