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.
- I think there are valid calls with mixing inline and trailing closures (notably `Debouncer`), so I’m considering whether we should disable that rule.
- The `forEach` rule is a little annoying because we have `forEach` on `SKDResponseArray`. But it caught two cases of using `forEach` on arrays, so I think it’s worth keeping.
This adds a sourcekitd plugin that drives the code completion requests. It also includes a `CompletionScoring` module that’s used to rank code completion results based on their contextual match, allowing us to show more relevant code completion results at the top.
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
Naming types in sourcekitd_functions.h `sourcekit_api_` instead of `sourcekitd_` indicates that these are types to be used with dynamically loaded sourcekitd libraries. It avoids confusion if sourcekitd is also linked, which adds the `sourcekitd_` symbols.
Adding nullability annotations to it is also just nice.
And some improved formatting never hurts.
This adds support for name translation between Swift anc clang languages to allow renaming across those language boundaries.
Rename is always initiated at the symbol’s definition, so when renaming an Objective-C symbol from Swift, the user is prompeted to enter the new Objective-C method name.
rdar://118996461
SourceKit-LSP supports explicit cancellation and thus we don’t need to do the implicit cancellation of cursor info and related identifiers on subsequent requests.
With this change, opening and editing a document no longer causes a non-cancellable AST build. Instead, all semantic information is retrieved via requests that can be cancelled (after we implement cancellation).
This allows us to cancel the semantic tokens request. It is also the last step to allow us to open and edit documents in syntactic-only mode.
It also means that we no longer need to send a `WorkspaceSemanticTokensRefreshRequest` to the client after sourcekitd has updated its semantic tokens since with the new design the `DocumentSemanticTokensRangeRequest` will simply return the results once it has the updated semantic token.
We weren’t semantically highlighting references to actors because we missed the `ref_actor` case from the sourcekitd `annotations` response.
Fixes#694
rdar://104573568
This is an implementation of LSP's semantic tokens for Swift. Both
lexical and semantic tokens are provided by using the syntaxmap and the
semantic annotations provided as part of SourceKit's open responses and
document update notifications.
While lexical tokens are parsed and stored in the DocumentManager
synchronously, semantic tokens are provided asynchronously. If an edit
occurs, tokens are automatically shifted by the DocumentManager. This is
especially relevant for lexical tokens, which are updated in deltas.
In addition, unit tests are added that assert that both lexical and
semantic tokens are provided and shifted correctly upon edits.
- Add UID for CollectExpressionType request
- Add ExpressionTypeInfo structure
- Add keys to support sourcekitd's CollectExpressionType
- Implement CollectExpressionType request
- Add SwiftLanguageServer.expressionTypeInfos
- Add InlayHint and supporting types
- Add InlayHintsRequest
- Add inlayHints handler stub
- Implement inlay hints request
- Update InlayHint to follow the current proposal
- # This is the commit message #11:
- ...as described in the LSP proposal
- Update doc comment on InlayHintsRequest
- Map inlay hints lazily
- Fix minor style issue
- Add new files to CMakeLists.txt
- Specify commit of the current inlay hints proposal state
- Add public, memberwise initializer for InlayHintsRequest
- assert(false) if deserializing ExpressionTypeInfos fails
- Add dispatch precondition to _expressionTypeInfos
- Add InlayHintsRequest to the builtinRequests
- Factor out function for querying document symbols for URI
- Only render inlay hints after variable bindings
- Test inlay hints on empty document
- Test inlay hints for some simple bindings
- Test ranged inlay hint requests
- Make sure that inlay hints are unique per position
- Test inlay hints for fields
- Apply various PR suggestions regarding inlay hints
- Update inlay hint tests and add case with explicit type annotations
- Continue iterating if an ExpressionTypeInfo fails to deserialize
* The interesting keys to split out are "code-completion options", not
any key that is used by completion.
* Sort the main key list
* Fix the name of the doc_brief key
