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.
- Rename methods to highlight that we’re talking about generated interfaces here, not `.swiftinterface` files
- Don’t open the generated interface in `documentManager`. Opening documents in `documentManager` should only be done by the `textDocument/didOpen` notification from the LSP client. Otherwise we might indefinitely keep the document in the document manager
- After getting the generated interface from sourcekitd, close the document in sourcekitd again. We don’t provide semantic functionality in the generated interface yet, so we can’t interact with the generated interface path. Before, we left it open in sourcekitd indefinitely.
- A couple of code simplifications.
Fixes#878
rdar://116705653
This was causing a non-deterministic test failure: When target preparation finishes while a diagnostic request is in progress, it will re-open the document, which calls `DiagnosticReportManager.removeItemsFromCache` for that document’s URI. With the old implementation, we would thus cancel the diagnostics sourcekitd request and return a cancelled error to the diagnostics LSP request.
While doing this, I also realized that there was a race condition: Document re-opening would happen outside of the SourceKit-LSP message handling queue and could thus run concurrently to any other request. This means that a sourcekitd request could run after `reopenDocument` had closed the document but before it was opened again. Introduce an internal reopen request that can be handled on the main message handling queue and thus doesn’t have this problem
There were two issues with Objective-C XCTest discovery:
1. We were relying on syntactic test discovery after a document is edited. But since we don't have syntactic test discovery for Objective-C tests, this meant that all tests would disappear as a document got edited. Until we get syntactic test discovery for Objective-C, use the semantic index to discover tests, even if they are out-of-date.
2. We were assuming that the `DocumentSymbols` request returned `[DocumentSymbol]` to find the ranges of tests. But clangd returns the alternative `[SymbolInformation]`, which meant that we were only returning the position of a test function’s name instead of the test function’s range.
rdar://126810202
When the semantic index is out-of-date, we currently purely rely on the syntactic index to discover tests and completely ignore data from the semantic index. This may lead to confusing behavior. For example if you have
```
class MightInheritFromXCTestCaseOrNot {}
class MyClass: MightInheritFromXCTestCaseOrNot {
func testStuff() {}
}
```
Then we don’t return any tests when the semantic index is up-to-date. But once the file is modified (either on disk or in-memory), we purely rely on the syntactic index, which reports `testStuff` as a test method. After a build / background indexing finishes, the test method disappears again.
We can mitigate this problem as follows: If we have stale semantic index data for the test file, for every test method found by the syntactic index, check if we have an entry for this method in the semantic index. If we do, but that entry is not marked as a test class/method, we know that the semantic index knows about this method but decided that it’s not a test method for some reason. So we should ignore it.
rdar://126492948
If the index for a given file is not up-to-date, perform a syntactic scan for tests within it.
This should allow editors to run the `textDocument/tests` request while the user is editing a file to scan it for test cases.
The naming was quite inconsistent here. Let’s rename these to `LanguageService` to highlight that they belong together.
- ToolchainLanguageServer -> LanguageService
- SwiftLanguageServer -> SwiftLanguageService
- ClangLanguageServerShim -> ClangLanguageService
