-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate to upstream LSP inlay hints request #465
Conversation
Thanks for continuing to work on this @fwcd. I would like to hold this PR back until LSP 3.17 has been finalized just so we don’t miss any last-minute changes to the official protocol. |
Nice, that looks really cool. Do you know if we can adjust the styling of the inlay type hints? In particular, use |
Yes, we should do that server-side now (which requires updating the tests too, previously the client implementing our non-standard inlay hints automatically appended the An interesting discussion regarding the styling can be found here: |
57337da
to
8945c2c
Compare
The inlay hints have been officially added to LSP 3.17, VSCode and inlay-hints-demo.mov(The video demo uses the new VSCode feature that keeps inlay hints only visible while ctrl+alt is pressed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you missed one data: LSPAny
field from the LSP spec, otherwise LGTM 👍
label: info.printedType | ||
.map { info -> InlayHint in | ||
let position = info.range.upperBound | ||
let label = ": \(info.printedType)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be really nice if we could use InlayHintLabelPart
s here and make each label part clickable and to jump to that type’s definition. But that’s definitely out-of-scope for this PR and would probably also require changes to sourcekitd
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, that would be a cool feature for a future PR.
@swift-ci Please test |
Would you mind squashing the commits? |
- 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.
670a696
to
818c44d
Compare
Done! |
@swift-ci Please test |
Inlay hints have been officially added to the VSCode API and are in the process of being officially added to the Language Server Protocol (LSP). As proposed in #406, this PR performs the final step of using the official LSP request for inlay hints (
textDocument/inlayHint
) instead of our current, non-standard request (sourcekit-lsp/inlayHints
).To do:
textDocument/inlayHint
)InlayHintCategory
toInlayHintKind
and represent it using an integerInlayHintPart
and the other parameters toInlayHint
(see here)TextEdit
that 'commits' the inlay hint as a type annotation to the the document (this will be possible once the newInlayHint
structure is implemented fully)sourcekit-lsp
with a recent version ofvscode-languageclient
and VSCode (see the PR invscode-swift
)See also:
8.0.1
)cc @ahoppen