Autocomplete suggestion changes to something random once selected

[tgross35]

rust-analyzer version: rust-analyzer 1.84.0-nightly (b19329a 2024-11-21)

rustc version: rustc 1.84.0-nightly (b19329a 2024-11-21)

editor or extension: helix 24.7 (079f5442)

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME)

repository link (if public, optional): reproduced in multiple repositories

code snippet to reproduce: working on minimal repro

Since about the past week I have been dealing with an issue where autocomplete suggestions change when I highlight them. This video explains it better:

The video shows the following:

• I type let mut px = PCt
• Arrow down to the suggested and expected PCtx
• Once the suggestion is highlighted in the dropdown, it replaces my PCt with PCtx which is expected. However, it deletes the space between = and PCt - that is weird.
• I hit escape to cancel, which deletes PCt*
• I start typing PCt again. RA again suggests PCtx
• I arrow down and highlight PCtx in the dropdown. RA replaces it correctly this time
• However, after about a half second, the suggested PCtx in the dropdown has changed to Either. This is completely random and makes no sense in the context (though what it suggests does seem to be consistent)
• I hit escape to cancel. For some reason, it replaces PCtx with Either

My only RA config is pretty minimal:

[language-server.rust-analyzer.config]
diagnostics.disabled = [ "inactive-code", "unlinked-file" ]

I am assuming this came from an RA update since it started somewhat recently (past week or two) and Helix hasn't had an update in a few months, but I haven't yet had a chance to see if it still happens with older versions. This problem happens pretty consistently across multiple repos.

Edit: this happens with other kinds of autocomplete suggestions too, it is doing things like changing some_func to panic!().

[tgross35]

Doing some light bisection. I have not been able to reproduce with these versions:

• rust-analyzer 1.82.0 (f6e511ee 2024-10-15)
• rust-analyzer 1.84.0-nightly (1e4f10b 2024-10-29)
• rust-analyzer 1.84.0-nightly (b91a3a0 2024-11-07)

With these, I have been able to cause the behavior pretty easily:

• rust-analyzer 1.84.0-nightly (90ab8ea 2024-11-14)
• rust-analyzer 1.83.0-beta.7 (b35ad722a4b 2024-11-22)
• rust-analyzer 1.84.0-nightly (b19329a 2024-11-21)

[schrottkatze]

experiencing this too, on helix as well (but helix master, thought that might be causing it but apparently not), on the last mentioned rust-analyzer version

[TheBearodactyl]

same exact problem here

[boraarslan]

Same problem on nvim after updating my rust-analyzer. Solution on #18536 did not work for me.

neovim version:

NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1731601260

rust-analyzer version: rust-analyzer 1 (327ab2958f 2024-11-24)

[Veykril]

@SomeoneToIgnore is this issue what was caused by your changes last month? (and hence was this fixed by #18503?). Pinging mainly because I have not been following up on the completions issues that occured while I was away :)

[SomeoneToIgnore]

Yes, this got exposed due to my changes, alas.
#18503 fixed things for all editors like Emacs (lsp-mode), Kate, Zed, etc.
Things were not really fixed in this PR for Helix and NeoVim because

• Helix does not support partial completions and does not re-query completions on the document changes, causing r-a to get a different completions list for resolving, messing up all indices and returning nonsense
  More context: Completion items change when cycling helix-editor/helix#12119 (comment)

• NeoVim looks anti-spec and odd, it does edit the text document on completion selection (before applying anything) and is declaring a very peculiar set of completion item properties it can resolve, which they do care to fix even after the PR is there: Make LSP completions resolve capabilities more spec-compliant hrsh7th/cmp-nvim-lsp#75

While being caused by different approaches, both cases boil down to a microsoft/language-server-protocol#2060 question but that is not answered still.

(Also, to me, it's not very clear how the additionalTextEdits were correctly resolved for them before (by sheer luck it seems)).

More general context can be found from
https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Completion.20IDs/near/484684205
message and below.

[Veykril]

Do both of these editors announce what they are in the handshake? If yes we could temporarily disable resolve support for them within the server.