Replace 'weak var' with 'weak let' for weak reference properties that are
set in init and never reassigned, using the Swift 6.3 feature introduced
by SE-0481.
Previously, language services were held in a global registry on
SourceKitLSPServer and shared across workspaces, requiring complex
lifetime tracking (isImmortal, shutdownOrphanedLanguageServices) to
decide when to tear them down. In practice, every language service
already stored workspace-specific properties (buildServerManager,
semanticIndexManagerTask), so sharing them across workspaces was never
truly safe. Giving each Workspace its own service instances simplifies
lifetime management: services are created when needed and shut down
with their workspace.
Remove LanguageService.isImmortal, the workspace parameter from
canHandle(toolchain:), and the initialize/clientInitialized protocol
requirements.
Introduce `SourceKitDCore` as the protocol boundary between dylib
lifecycle management and the high-level `SourceKitD` API. Its single
lifecycle entry point, `initializeService(api:notificationCallback:)`,
receives the already-loaded `sourcekitd_api_functions_t` from
`SourceKitD.init(core:)`.
`SourceKitDCoreImpl` is the standard implementation: `init` opens the
dylib; `initializeService` registers any plugin paths, calls
`api.initialize()`, and wires the notification handler; `deinit` calls
`shutdown()` and closes the handle. Pre-initialized conformances
implement `initializeService` as a no-op.
Wire a `sourcekitdCoreInjector` hook through `Hooks` so an embedding
host can return a pre-initialized `SourceKitDCore` for a given toolchain
path, preventing `sourcekitd_initialize()` from being called a second
time.
Declare `SourceKitDCoreForPlugin` at its use sites so each call site
can express the exact deinit behavior it needs: `dlclose` for handles
acquired via `RTLD_NOLOAD`, and `leak` for externally-owned handles.
Previously, we always recomputed the inlay hints by calling into
SourceKit. If the document that we compute inlay hints for has recently
changed, SourceKit may need a bit of time to recompute the semantic
analysis. The inlay hints may thus need roughly 200-700ms to be
computed. This causes flickering in VSCode as it removes the old inlay
hints immediately and only displays them again when SourceKit-LSP
returned them.
With this commit we cache the inlay hints and recompute them in the
background. After the recompute is finished we use
`workspace/inlayHint/refresh` request to tell the client to refresh its
inlay hints. On each textDocument/didChange request the cached inlay
hints are shifted according to the text edits to ensure their positions
are still correct. This avoids the flickering as we can always return
the cached inlay hints immediately. The returned hints may however
temporarily show outdated type information until the background
recompute is finished.
This commit adds support for passing experimental features to SwiftParser through build settings. It includes:
- Changes to SwiftLanguageService.swift to handle experimental features
- Updates to SyntaxTreeManager.swift to pass these features to the parser
- E2E tests verifying experimental features work with the SyntaxTreeManager
This enables hierarchical selection expansion in supported editors.
Selection ranges are computed from the AST by walking upward from the
smallest enclosing node to the root. This is implemented by AST nodes
conforming to the `SelectionRangeProvider` protocol. Most nodes use a
default implementation which returns the node's `trimmedRange`.
Other nodes are special-cased to adjust the returned selection ranges
based on other factors.
Return empty response when cursor is on literal tokens (strings,
integers, floats, booleans, nil) since they have no declaration.
Resolves#2368
Co-Authored-By: clemo97 <lumumbaclement@gmail.com>
Implements resolveProvider for inlay hints to enable navigating to type
definitions. When an inlay hint showing a type is resolved, the server
looks up the type's definition location using cursorInfo and the index.
- store variable position in InlayHint.data for resolution
- add inlayHintResolve to LanguageService protocol
- implement resolve handler using cursorInfo and index lookup
- enable resolveProvider: true in capabilities
- add test for resolve functionality
Addresses #2318
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
Replace usages of `Optional.map` and `Optional.flatMap` by if expressions or other expressions.
I personally find `Optional.map` to be hard to read because `map` implies mapping a collection to me. Usually the alternative constructs seem clearer to me.
- 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
The idea is pretty simple: When `MemberImportVisibility` is enabled, we know that imports can only affect the current source file. So, we can just try and remove every single `import` declaration in the file, check if a new error occurred and if not, we can safely remove it.
We previously waited for the initialization response from the build server during the creation of a `Workspace` so that we could create a `SemanticIndexManager` with the index store path etc. that was returned by the `build/initialize` response. This caused all functionality (including syntactic) of SourceKit-LSP to be blocked until the build server was initialized.
Change the computation of the `SemanticIndexManager` and related types to happen in the background so that we can provide functionality that doesn’t rely on the build server immediately.
Fixes#2304
Depends on https://github.com/swiftlang/swift/pull/83378
---
Adds support for the LSP signature help request.
> [!NOTE]
> As of https://github.com/swiftlang/swift/pull/83378, SourceKitD still
doesn't separate parameter documentation from the signature
documentation and thus parameters don't have their own separate
documentation. This should just work once SourceKitD implements this
functionality and we'll only need to modify the tests.
With the introduction of secondary language services, we don’t expect every language service to implement every request anymore. To simplify the addition of language services like `DocumentationLanguageService` add default implementations for methods that satisfy the following criteria:
- `SourceKitLSPServer` does not expect side effects to happen when they are called
- The method can throw or there is a reasonable default value
- It is reasonable to expect that not all language services need to implement it
Rintaro Ishizaki
25harsh
Alex Hoppen
Steffeeen
Pavel Kroupa
loveucifer
Ahmad Ayman Mansour
Adam Ward
Anthony Latsis
Owen Voorhees
Ahmed Elrefaey
Matthew Bastien