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
We are moving to a better model for TSC's path APIs in apple/swift-tools-support-core#353. The previous API is still available (but deprecated) as much as possible, but since SourceKit-LSP was using `resolveSymlinks` (which is now throwing) quite a bit, there are some changes necessary.
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.
Add a dependency on TSCBasic for LanguageServerProtocol. This dependency was added recently via an `import` and was updated in Package.swift but was missed in the CMake build.
When converting the URI to a path string, ensure that we convert to the
file system representation. This is important as this ensures that we
are always passing SourceKit the native path string. With this change,
the code completion behaviour for the LSP test suite on Windows is
repaired.
- Add typeHierarchyProvider
- Implement prepareTypeHierarchy request
- Add supertype and subtype request handlers
- Implement supertypes and subtypes request
- Display location and conformance of extensions in type hierarchy
- Include extensions in the type hierarchy
- Include module names in type hierarchy
- 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 makes SourceKitServer keep track of multiple workspaces and their handling. It does not include the functionality to determine which workspace a file belongs to.
This makes SourceKitServer keep track of multiple workspaces and their handling. It does not include the functionality to determine which workspace a file belongs to.
This adjusts the sourcekit-lsp build to use static linking for the
internal libraries. It is not currently possible to build
SourceKitLSP.dll as that requires re-exporting the interfaces from the
consumed modules. However, this allows us to reduce the overall size of
the distribution of SourceKit-LSP by ~1 MiB and reduces the
distributed file set. The values here assume partial static linking of
swift-package-manager, which helps reduce the total size.
Before:
228,352 BuildServerProtocol.dll
1,773,056 LanguageServerProtocol.dll
114,688 LanguageServerProtocolJSONRPC.dll
49,152 LSPLogging.dll
262,656 SKCore.dll
54,784 SKSupport.dll
80,896 SKSwiftPMWorkspace.dll
150,528 SourceKitD.dll
645,632 SourceKitLSP.dll
70,144 sourcekit-lsp.exe
3,429,888 bytes
After:
2,416,640 sourcekit-lsp.exe
2,416,640 bytes
This will add an additional link request for dispatch and Foundation
libraries. These are really required on non-Darwin targets, and should
be satisfied either by the library search path or by explicitly
indicating where the dependencies can be found.
This adds support for clangd commands for clients which support
dynamic registration (including VS Code), as well as fixes an
issue which prevented clangd's code actions from working.
Also added a test to ensure the clangd code actions work, as well as regenerated the Linux test main (which was missing some other newly added tests).
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
Diagnostic tags represent additional metadata about a diagnostic, e.g.
for unused variables or deprecations. This lets editors e.g. style such
diagnostics in a special way, e.g. by striking through deprecated
methods or dimming unused values.
- 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
This allows building without dispatch and Foundation build roots, which
allows for a multi-phase build. This is intended to support the Windows
staged build where dispatch and Foundation are part of the SDK and
SourceKit-LSP is part of the devtools.
By default, print 1-based line/column numbers using the defacto standard
line:column format. In debug print, continue to use the 0-based values
to match the constructor.
