We were registering new diagnsotics in `currentDiagnostics` when the diagnostics got pushed to us by sourcekitd, but not when they were pulled using the diagnostic request.
Fixes#776
rdar://112539108
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
The dependency on `TSCUtility` was strictly for identifying the platform
of execution. This logic is relatively self-contained and effectively an
extension over an enumeration. Replicate this logic with updates for new
syntactic improvements. This allows us to partially reduce dependency on
swift-tools-support-core. The dependency on TSCBasic is more complicated
to remove due to the extensive use of `AbsolutePath`.
Co-authored-by: Alex Hoppen <alex@alexhoppen.de>
Building upon the infrastructure that requests the lexical structure of the document from SwiftSyntax, redo the folding ranges request using the tree directly. This corrects a number of inconsistencies in the tests mostly due to incorrect SourceLocations in the semantic ASTs and the line comment merging logic.
Re-core the "lexical" token stream on top of SwiftSyntax and call into the parser to (re-)generate these "lexical tokens" when the document changes. Leave the semantic tokens alone since they take some non-zero amount of name lookup to fully resolve references to fully replicate.
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.
Rather than treating the filename as an opaque string and splitting on
`/`, use `AbsolutePath` to perform the `basename` operation on the path.
This ensures that we split the path properly on platforms which do not
use the POSIX path separator `/`.
Explicitly import interfaces from TSCBasic which now allows us to
identify all the swift-tools-support-core interfaces which are in
use in SourceKit-LSP.
Replace the use of the deprecated `Lock` from swift-tools-support-core
with `NSLock`. The benefit of the deprecated interface was the
`withLock` function which is easily replicated and very unlikely to
change. By doing so we avoid the warnings about `Lock` being deprecated
when building SourceKit-LSP.
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.
This adds a check when creating a `TextEdit` to return `nil` if both the fixit and the replacement being used to create a `TextEdit` are empty. A `TextEdit` being created like this can cause a crash.
Rather than asserting, raise an error for the user and abort the
operation. This is motivated by the desire to get the test suite mostly
working on Windows so that the underlying issues can be worked through
more easily.
- 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
- Add prepareCallHierarchy handler
- Register callHierarchyProvider capability
- Use proper symbol kind in prepareCallHierarchy
- Stub out implementation of outgoingCalls
- Encode usr and uri in indexToLSPCallHierarchyItem
- Extract call hierarchy item data parser
- Implement incomingCalls
- Add Call Hierarchy to the list of supported features
- Resolve caller/callee definition locations for call hierarchy
This allows sourcekit-lsp to make use of the path remappings recently added to
the index store and IndexStoreDB to remap remote paths into local paths
when loading index data locally.
These remappings can be provided via the `-index-prefix-map` command line flag to sourcekit-lsp or via the `BuildSystem` integration point.
We only open a document e.g. with the `FoldingRanges:` prefix to get the document structure as a one-off task, so we should be closing it afterwards.
Fixes#553 (rdar://93154201)
A didChangeWorkspaceFolders notification might cause documents that are already open to now be considered part of a different workspace. To reflect this, close documents whose workspace has changed in the old workspace and re-open them in the new workspace.
rdar://94026341 [#557]
- 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.
