- 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.
Implement rudementary support for `DidChangeWatchedFileNotification` for SwiftPM projects: When a file is added, reload the Swift package to compute build settings for it.
This enables proper semantic functionality added to the project after the LSP server was started.
Resolves SR-15633
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).
- 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).
A number of tests were failing with the -Onone lifetime changes.
Regardless of what happens with that change, I'd like to keep our tests
passing with the stricter rules since we also test in release builds.
