Generate swiftinterface for symbol lookup
When a symbol definition returns it is in a swiftinterface file, create textual version of swiftinterface and return that in response.
Extend OpenInterface to also seatch for a symbol
Fix warning
Syntax changes after review
Move module name split into OpenInterfaceRequest
Use group names when running open interface request
Requested changes from PR
rename symbol to symbolUSR
Cleanup OpenInterfaceRequest.init
Fix tests
Added testDefinitionInSystemModuleInterface
Use SwiftPMPackage test module
Added version of buildAndIndex that includes system symbols
Merge buildAndIndexWithSystemSymbols with buildAndIndex
Added specific test project for system swiftinterface tests
Add multiple tests for various system modules
A declaration request is similar to a definition request, except that it is expected to return (potentially) many results across the workspace for a given reference. For example, an inline function or macro may have many declarations in the workspace, but only one "good" or canonical definition. For now, this is only implemented by forwarding the request on to clangd since I'm unfamiliar with a SourceKit query for this.
For languages like Swift that lack such a sharp declaration/definition split, we could potentially use this request to provide navigable metadata on linked definitions. For example, the declaration for a type reference would include all extensions of that type in the workspace.
- Use official textDocument/inlayHint request
- Rename InlayHintCategory to InlayHintKind
- Additionally, represent it using an Int, as in the proposed LSP API.
- Add inlay hint client capabilities
- Add inlay hint server capabilities
- Add dynamic registration of inlay hint request
- Rename InlayHintsRequest -> InlayHintRequest
This is to be consistent with the request itself being named in singular
in LSP and the other requests (e.g. DocumentSymbolRequest).
- Forward inlay hint requests to clangd
- Add colon before inlay hints
- Add other properties to InlayHint
- Add InlayHintLabel structures
- Conform InlayHintLabel to ExpressibleByStringX protocols
- Attach TextEdit to inlay hints for committing them
- Add InlayHint.data
- Fix InlayHintTests
We need to include text edits in the expected inlay hints.
This appears to have been accidentally removed in
17f656865d, the `children` field is
optional in the LSP spec.
Change-Id: I1055658c8f09873279d676fee0daff02fa59e3f8
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
- Add LSP types for semantic highlighting
- Limited to clients which support dynamic registration for semantic highlighting
- Requires clangd 11 or later
Using dynamic registration (when supported by the client) allows
us to provide different completion options for ObjC and Swift
files.
We should be able to expand this to other capabilities in the future
(e.g. semantic highlighting, execute command support).
* Add LSP types and server stubs for call hierarchy support
* Update CMakeLists.txt for new LSP types
* Call hierarchy misc fixes
* Minor PositionRangeArray fixes to simplify codable conformance
* Add CodingTests for PositionRangeArray and CallHierarchy encoding
* Additions to the LSP module for `workspace/didChangeWatchedFiles`
We can then use this functionality to allow a `BuildSystem` to watch
files (e.g. via the client or even in-process file watching),
which would allow us to do things like detect new files and provide
accurate build settings for them.
* Improve #file and #line for LSP test errors
Also regenerate Linux main
* Add `LSPAnyCodable` protocol requirement to RegistrationOptions
* Don't encode an optional documentSelector to null
* Skip running `testSourcekitdCrashRecovery` when not on macOS
* Send `didSave` notifications to clangd if it supports it
- Minor update to the LSP protocol for `didSave` and `colorProvider` to be more in line with the spec
- Only send color requests over to clangd if it supports it
Rationale for this change: clangd recently implemented didSave support,
it is used to rebuild preambles when the user edits a header file
referenced by an open file.
Change-Id: Ie6e2198bdeccb9d1b4083806c254475baadc2d2b
Remove `settings(for:)` from the BuildSystem API in favor of the change callback
- With the `settings(for:)` method removed, we instead block on a
callback from the `BuildSystemManager` which itself handles
the primary build system callback in conjunction with the fallback
system
- We queue up notifications / requests that reference documents
until we receive the callback.
- Remove language from FileBuildSettings as it is no longer needed,
Swift-specific working dir fixes are now in SwiftCompileCommand
- registerForChangeNotifications should inform its delegate
asynchronously instead of immediately
The client guarantees that unsupported kinds will be handled, and in
practice some clients, such as Sublime's LSP plugin, use
`"codeActionKind":{"valueSet":[]}`, since they support all kinds anyway.
This behaviour was also clarified in a [spec issue
report](https://github.com/Microsoft/language-server-protocol/issues/620)
where it was confirmed the server can send any actions it wants. It
seems preferable to ignore it.
Request types should always have the suffix Request and notifications
should end with Notification.
Also moved all request and notification types into separate folders to
reduce the number of files in the LanguageServerProtocol folder.
