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.
- 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
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.
Determining which workspace a document belongs to is potentially non-trivial (although it shouldn’t be too expensive either). But since it’s executed for every request, cache it.
This sets the stage for multi-workspace support. Everything should be handled internally, we are just missing the API to actually open multiple workspaces at this point.
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.
When we introduce multiple workspaces, they need to share the same DocumentManager so we don’t accidentally open a Swift file twice in two workspaces that share the same `SwiftLanguageService`. Thus, `SourceKitServer` needs to start owning the document manager.
When we support multiple workspaces on one SourceKit-LSP instance, there won’t be a unique workspace anymore. Each request handler should determine the workspace it wants to use on its own.
Determining which workspace a document belongs to is potentially non-trivial (although it shouldn’t be too expensive either). But since it’s executed for every request, cache it.
This sets the stage for multi-workspace support. Everything should be handled internally, we are just missing the API to actually open multiple workspaces at this point.
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.
When we introduce multiple workspaces, they need to share the same DocumentManager so we don’t accidentally open a Swift file twice in two workspaces that share the same `SwiftLanguageService`. Thus, `SourceKitServer` needs to start owning the document manager.
When we support multiple workspaces on one SourceKit-LSP instance, there won’t be a unique workspace anymore. Each request handler should determine the workspace it wants to use on its own.
Similar to how we reload the package if Package.swift is changed, we also watch `compilation_database.json` and `compile_flags.txt` and notify the build system delegate that build settings changed if these files are modified.
rdar://92388223 [#486]
Especially in test we would sometimes end up in situations where the SourceKitServer (i.e. the main sourcekit-lsp handler) is being deallocated before clangd has finished shutting down. This can result in clangd sending us notifications while SourceKitServer is halfway deallocated and thus cause crashes due to memory corruption.
To fix the issue, wait until all toolchain servers have shut down before sending a response to the ShutdownRequest.
This explicitly identifies the TSCUtility interfaces that SourceKit
depends on. This helps identify a "burn down list" of interfaces that
remain in TSC(Utility) which are in use. As these interfaces are
replaced, we can easily monitor the remaining interfaces that are in
use.
This reduces the dependency on the `TSCLibc` module which was not
actually used for anything but for importing the C library in
`SKSupport`. Although on Apple platforms and Linux this could largely
be dealt with by statically linking, Windows does not support static
linking of Swift content properly yet. This avoids the dependency on
the library instead.
