Hash completion items to properly match them during /resolve #18653

SomeoneToIgnore · 2024-12-09T22:52:07Z

Follows #18547 (comment) proposal and adds completion items hashing, using all their data possible, that does not change between the edits.

…esolve query

SomeoneToIgnore

My only concern is how relatively fragile this is, if another field is added or some fields start to alter between text edits, but otherwise it seems to work on VSCode and Helix during my manual testing.

cc @Veykril as it would be good to use this for some while to see if that sporadic error is gone with this build.

SomeoneToIgnore · 2024-12-09T22:53:17Z

crates/ide-completion/src/item.rs

@@ -346,8 +346,7 @@ pub enum CompletionItemKind {
 impl_from!(SymbolKind for CompletionItemKind);

 impl CompletionItemKind {
-    #[cfg(test)]


This seems to be quite an odd change, but it was quite tempting to reuse existing &str producer for this large enum.

As an alternative, I can copy this into the module with the hashing function, are there better ideas?

Can't we just make CompletionItemKind and SymbolKind Hash?

Oh I see, tenthash doesn't accept hash things, only byte slices...

crates/rust-analyzer/src/lib.rs

SomeoneToIgnore · 2024-12-09T22:58:40Z

crates/rust-analyzer/src/lsp/ext.rs

@@ -826,7 +826,8 @@ pub struct CompletionResolveData {
    pub imports: Vec<CompletionImport>,
    pub version: Option<i32>,
    pub trigger_character: Option<char>,
-    pub completion_item_index: usize,
+    pub for_ref: bool,
+    pub hash: [u8; 20],


We can reduce the JSON size with https://github.com/cessen/tenthash/blob/159da57b120bf2abcdd42532d17a7ae2957f98b8/tenthash-rust/tests/test_vectors.rs#L17 but not sure how appropriate this conversion is, any ideas?

I would do something like base64, that encoding is just a hex string which is pretty standard to use for hashes but not necessairily the most information dense (compared to base64)

Thanks, had applied Base64 and it does trim the character number by half:

Before:
"hash":[215,92,116,28,211,148,173,32,58,55,147,15,75,30,169,165,93,8,60,63]

After:
"hash":"11x0HNOUrSA6N5MPSx6ppV0IPD8="

Seems like a good thing to do.

crates/rust-analyzer/src/lsp/to_proto.rs

crates/rust-analyzer/src/lib.rs

Veykril · 2024-12-10T10:14:06Z

crates/ide-completion/src/item.rs

@@ -346,8 +346,7 @@ pub enum CompletionItemKind {
 impl_from!(SymbolKind for CompletionItemKind);

 impl CompletionItemKind {
-    #[cfg(test)]


Can't we just make CompletionItemKind and SymbolKind Hash?

Veykril · 2024-12-10T10:15:22Z

crates/ide-completion/src/item.rs

@@ -346,8 +346,7 @@ pub enum CompletionItemKind {
 impl_from!(SymbolKind for CompletionItemKind);

 impl CompletionItemKind {
-    #[cfg(test)]


Oh I see, tenthash doesn't accept hash things, only byte slices...

crates/rust-analyzer/src/lsp/to_proto.rs

pascalkuthe

this is a much more robust approach, thanks for the fast turnaround!

pascalkuthe · 2024-12-10T10:22:40Z

crates/rust-analyzer/src/handlers/request.rs

+
+    let Some(corresponding_completion) = completions.into_iter().find(|completion_item| {
+        let hash = completion_item_hash(completion_item, resolve_data.for_ref);
+        hash == resolve_data.hash


I think may be a good idea to first check if the labels are identical and only compute and compare the hash if they are:

this will reduce computational requirements a bit since hash is only computed for any realistic candidates

as a bonus it makes collisons even more unlikely

Nice idea.

It's a bit tricky because LSP completion items get their labels changed compared to the original ones, but luckily only by adding a suffix, so we can still reduce the computations with a starts_with check.

pascalkuthe · 2024-12-10T10:26:26Z

crates/rust-analyzer/src/lsp/ext.rs

@@ -826,7 +826,8 @@ pub struct CompletionResolveData {
    pub imports: Vec<CompletionImport>,
    pub version: Option<i32>,
    pub trigger_character: Option<char>,
-    pub completion_item_index: usize,
+    pub for_ref: bool,
+    pub hash: [u8; 20],


I would do something like base64, that encoding is just a hex string which is pretty standard to use for hashes but not necessairily the most information dense (compared to base64)

* Exclude documentation field from hashing * Do less cloning during initial completion list generation

* Use Base64 to minify the hash representation in the JSON data * Do hash checks only for items with similar labels

tgross35 · 2024-12-11T09:46:14Z

Would it be possible to do a sync soonish? I don't think either of the fixes have made it to r-l/rust so nightly is still buggy.

Edit: thanks Inicola, done in rust-lang/rust#134170

SomeoneToIgnore added 5 commits December 9, 2024 22:26

Draft completion hashing

62d97d9

Always compute the hash when r-a wants the imports to be resolved

d348ffb

Stop excluding Helix from the general resolve path

5906bda

Unite more bool hashing

b59b2fb

Avoid hashing completion-related ranges as those may change during /r…

89c2aae

…esolve query

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 9, 2024

SomeoneToIgnore commented Dec 9, 2024

View reviewed changes

Clippy fixes

d8d35db

This was referenced Dec 9, 2024

Autocomplete suggestion changes to something random once selected #18547

Closed

Make LSP completions resolve capabilities more spec-compliant hrsh7th/cmp-nvim-lsp#75

Closed

Veykril reviewed Dec 10, 2024

View reviewed changes

pascalkuthe reviewed Dec 10, 2024

View reviewed changes

SomeoneToIgnore added 2 commits December 10, 2024 12:33

Address the feedback from Veykril

2529e9e

* Exclude documentation field from hashing * Do less cloning during initial completion list generation

Address the feedback from pascalkuthe

4169926

* Use Base64 to minify the hash representation in the JSON data * Do hash checks only for items with similar labels

pascalkuthe approved these changes Dec 10, 2024

View reviewed changes

Veykril added this pull request to the merge queue Dec 11, 2024

Merged via the queue into rust-lang:master with commit 087cb62 Dec 11, 2024
9 checks passed

SomeoneToIgnore deleted the hash-completions branch December 11, 2024 08:17

lnicola mentioned this pull request Dec 11, 2024

Completion items change when cycling helix-editor/helix#12119

Closed

traviscross mentioned this pull request Dec 27, 2024

Auto-imports broken in Emacs lsp-mode by commit 62d97d9 #18767

Closed

RoloEdits mentioned this pull request Jan 6, 2025

in windows autocomplete + tab content change to another helix-editor/helix#12427

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hash completion items to properly match them during /resolve #18653

Hash completion items to properly match them during /resolve #18653

SomeoneToIgnore commented Dec 9, 2024

SomeoneToIgnore left a comment

SomeoneToIgnore Dec 9, 2024

Veykril Dec 10, 2024

Veykril Dec 10, 2024

SomeoneToIgnore Dec 9, 2024

pascalkuthe Dec 10, 2024

SomeoneToIgnore Dec 10, 2024

Veykril Dec 10, 2024

Veykril Dec 10, 2024

pascalkuthe left a comment

pascalkuthe Dec 10, 2024

SomeoneToIgnore Dec 10, 2024

pascalkuthe Dec 10, 2024

tgross35 commented Dec 11, 2024 •

edited

Loading

Hash completion items to properly match them during /resolve #18653

Hash completion items to properly match them during /resolve #18653

Conversation

SomeoneToIgnore commented Dec 9, 2024

SomeoneToIgnore left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pascalkuthe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tgross35 commented Dec 11, 2024 • edited Loading

tgross35 commented Dec 11, 2024 •

edited

Loading