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.
Instead of querying the index twice (once for up-to-date files, once for
outdated ones), collect file modification timestamps during the syntactic
scan phase and use them to filter a single semantic index query.
For files that don't support syntactic scans, use the semantic index
results even if outdated.
Also extracts symlink-aware mtime resolution into URL.fileModificationDate
and exposes snapshotHasInMemoryModifications(_:) on DocumentManager.
Previously, test discovery used the semantic index as the primary
source and fell back to the syntactic index only for files where the
semantic index was out-of-date. This meant test locations came from the
semantic index, which only records a point position rather than the
full symbol range.
Flip the priority: use syntactic scan results as the primary source
(which have correct location ranges) and supplement with semantic index
results. The semantic results are range-fixed via
'textDocument/documentSymbol' before being returned.
This logic is unified into a single 'combineTests' helper shared by
both 'workspaceTests' and 'documentTests'.
Also fix 'SyntacticSwiftXCTestScanner' to emit extensions as proper
'AnnotatedTestItem' nodes (with 'isExtension: true') rather than a flat
list of methods, so extension test methods are correctly merged into
their class via 'mergingTestsInExtensions'. The class and extension
visitors are unified through a shared 'handleClassOrExtension' helper.
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.
- Use cursorInfo USR lookup instead of index (more accurate)
- Add document version tracking to reject stale resolve requests
- Make InlayHintResolveData conform to LSPAnyCodable
- Reference swiftlang/swift#86432 for mangled type workaround
- cursorInfoFromTypeUSR takes DocumentSnapshot for version safety
- Remove TypeDefinition.swift (defer to follow-up PR)
- Remove unnecessary comments
- Tests work without index
Add support for the textDocument/typeDefinition LSP request, which
finds the type of the symbol at a given position and returns the
location of that type's definition.
This uses the same type definition lookup mechanism as the inlay hint
resolution feature, which queries cursorInfo for the new type
declaration location fields (typeDeclFilePath/Line/Column) with
fallback to index lookup using typeDeclUsr.
Fixes#548
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
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.
`SyntacticTestIndex` queries all language services for a document for its syntactic test items. This caused `syntacticDocumentTests not implemented in DocumentationLanguageService` to be logged for every Swift file in the project. Remove the default implementation of `syntacticDocumentTests` in `LanguageService` and instead provide an implementation that returns an empty array in `DocumentationLanguageService`.
While at it, also log the files for which unimplemented methods are called on `LanguageService`. This makes it easier to dermine why they are called.
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
This cleanly separates the responsibilities for handling documentation from those of handling Swift files. It also simplifies providing docc support for clang because we just need to implement the two `symbolGraph` methods in `ClangLanguageService` and can re-use the remaining infrastructure from `DoccLanguageService`.
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.
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
Even after sending the `dependencyUpdated` request to sourcekitd, the code completion session has state from before the AST update. Close it and open a new code completion session on the next completion request.
Adds a response to the textDocument/codeLens request that returns two
code lenses on the `@main` attribute of an application.
The LSP documentation breaks out the code lens requests into a
[`Code Lens Request`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeLens)
and a
[`Code Lens Resolve Request`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeLens_resolve),
stating this is for performance reasons. However, there is no intensive
work we need to do in order to resolve the commands for a CodeLens;
we know them based on context at the time of discovery. For this reason
we return resolved lenses with Commands for code lens requests.
A missing piece is only returning code lenses if the file resides in an
executable product. To my knoledge Libraries and Plugins can't have an
`@main` entrypoint and so it doesn't make sense to provide these code
lenses in those contexts.
Some guidance is required on how to best determine if the textDocument
in the request is within an executable product.
`testCodeLensRequestWithInvalidProduct` asserts that no lenses are
returned with the `@main` attribute is on a file in a `.executable`, and
is currently failing until this is addressed.
Change a l public declarations to the `package` access level, accept for:
- The `LanguageServerProtocol` module
- The `BuildServerProtocol` module
- `InProcessClient.InProcessSourceKitLSPClient`
- `LanguageServerProtocolJSONRPC` (I would like to create a more ergonomic API for this like `InProcessSourceKitLSPClient` in the future, but for now, we’ll leave it public)
Unfortunately, our pattern of marking functions as `@_spi(Testing) public` no longer works with the `package` access level because declarations at the `package` access level cannot be marked as SPI. I have decided to just mark these functions as `package`. Alternatives would be:
- Add an underscore to these functions, like we did for functions exposed for testing before the introduction of `SPI`
- Use `@testable` import in the test targets and mark the methods as `internal`
Resolves#1315
rdar://128295618
fix!: remove `documentManager` property
fix!: remove `documentManager` in constructor
fix: added documentManager as a computed Property
fix: remove old documentmanager resetting step
fix!: get throws instead of crashing server
fix: throw ResponseError instead of NSError
fix: adding try & orLog where necesary
fix: refined orLog usage
style: ran swift-format
fix: document being opened twice
fix(DocumentManager): remove unwanted comments
lint: ran swift format
deleted OpenInterfaceRequest.swift and moved GeneratedInterfaceDetails to LanguageService.swift
replaced usages by passing its members as parameters directly, refactored usage of TextDocumentIdentifier to DocumentURI
removed from Messages.builtinRequests
removed from SwiftInterfaceTests
removed from Documentation/`LSP Extensions.md`
removed from Sources/LanguageServerProtocol/CMakeLists.txt
The idea here is to unify the different ways in which we can currently set options on SourceKit-LSP in a scalable way: Environment variables, command line arguments to `sourcekit-lsp` and initialization options.
The idea is that a user can define a `~/.sourcekit-lsp/.sourcekit-lsp` file (we store logs in `~/.sourcekit-lsp/logs` on non-Darwin platforms), which will be used as the default configuration for all SourceKit-LSP instances. They can also place a `.sourcekit-lsp` file in the root of a workspace to configure SourceKit-LSP for that project specifically, eg. setting arguments that need to be passed to `swift build` for that project and which thus also need to be set on SourceKit-LSP.
For compatibility reasons, I’m mapping the existing command line options into the new options structure for now. I hope to delete the command line arguments in the future and solely rely on `.sourcekit-lsp` configuration files.
Environment variable will be migrated to `.sourcekit-lsp` in a follow-up commit.
Rintaro Ishizaki
Alexander Skvortsov
Pavel Kroupa
Steffeeen
loveucifer
Alex Hoppen
Adam Ward
Owen Voorhees
Ahmed Elrefaey
Matthew Bastien
MahdiBM
Lokesh T R
Paul LeMarquand
Louis Qian
Kai Lau