When `commit.gpgsign = true` is enabled globally, signing fails because
the author 'Dummy <noreply@swift.org>' likey has a no configured GPG
key, causing test failures.
Apply the following changes:
- Check for the presence of `#Playgrounds` textually before getting the module name in `SwiftPlaygroundsScanner`. This is important because getting the module name requires us to get build settings for the file, which can be expensive. Do the cheaper check first
- Make `syntacticTests` and `syntacticPlaygrounds` closures capture the workspace instead of passing the workspace from the `SwiftSyntacticIndex` back out. I like this better because now we can’t accidentally pass the wrong workspace to a `SwiftSyntacticIndex`, eg. to `buildTargetsChanges`.
- Capture the initialize result in `TestSourceKitLSPClient` instead of using `postInitialization` to capture the result
- Minor cleanup of unnecessary abstractions, likely artifacts of earlier iterations
- Restructure tests so that every test has its own list of source files, allowing for easier local reasoning – turns out some of these tests didn’t even need to open a workspace, just to check the initialize response
- 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
