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
internal: Resolve inlay hint data lazily #15522
Conversation
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.
This does reduce the amount of data we sent over the lsp now which is great! But this does not close the linked issue as we still generate all the tooltips on the initial request on the server (while we don't have to). I'm fine with merging this without that being resolved though for the time being.
☔ The latest upstream changes (presumably #15548) made this pull request unmergeable. Please resolve the merge conflicts. |
Skip every propery set in inlay hint client resolve capabilities, reducing overall json footprint.
479bbd8
to
caf0185
Compare
28cd9de
to
7b3dba5
Compare
Omit sending inlay hint resolve data if inlay has no properties that client resolve capabilities support.
Alright, let's see how this goes |
Thank you for all your time taken for this series' review and discussions. |
Thank you for tackling (parts of) that issue, inlay hints are (I think, never really checked) way too slow right now and certainly too expensive |
☀️ Test successful - checks-actions |
I think location links for param inlay hints don't work after this PR (they do work for type inlay hints). Maybe another vscode bug? |
Definitely not VSCode to blame this time, I have created a PR to fix this: #16089 |
…lution, r=Veykril Query for nearest parent block around the hint to resolve This way, parameter hints will be found for resolution and #15522 (comment) will be fixed Hopefully that also helps with whatever else (lifetimes', etc.) hints in #13962 > hints are resolved by querying for textDocument/inlayHint with hint's position turned into a [position-1, position+1] range (instead of the original, much wider document range). > > This might lead to issues in the future, with e.g. lifetime hints (currently there's nothing to resolve for them and it's fine) that belong to a certain position, but need to have textDocument/inlayHint query for much bigger range than their position+/-1
Part of #13962
Support https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#inlayHint_resolve better, by omitting all inlay hint fields specified in the client hint resolve capabilities.
Current list of all capabilities possible to resolve later:
and every one specified in the client capabilities is now resolved by r-a, being omitted in the initial response.
When editing
inlay_hints.rs
file around line457
with no resolve capabilities, I getresolved json, 10803 characters
for the visible editor range alone, pretty much repeated on every consequent edit.
With this patch and all inlay hint resolve capabilities enabled, for the same example I observe quite a footprint reduction:
unresolved json, 4142 characters
with all unresolved parts needing only for navigation, hover or applying the hint edit — dynamic parts that are made after mouse hover or similar events, that resolve the hint data.