Incorrect textDocument/rename response when multiple edits on same document.

[martskins]

I just noticed that when issuing a textDocument/rename request on a file that has N occurrences of the symbol to be renamed, rust-analyzer replies with N TextDocumentEdits with a single TextEdit in it, whereas other servers reply with a single TextDocumentEdit with N TextEdits.

A TextDocumentEdit describes all changes on a version Si and after they are applied move the document to version Si+1.

This, according to the specification (above), seems incorrect to me, as applying a TextDocumentEdit effectively changes the version of the document, and any subsequent applies to the older version are potentially not valid anymore. More importantly it states that a TextDocumentEdit describes all changes on a version.

This is affecting LanguageClient-neovim right now, as filed in autozimu/LanguageClient-neovim#1055, when there are two occurrences of that symbol in the same line. If the leftmost edit is applied first, then the range for the rightmost edit is invalid, as the document has changed. When all the edits for a document are listed in a single TextDocumentEdit, LanguageClient-neovim sorts those edits by character and applies them from right to left, but given the current response this is not possible, as there is a single edit for each text document (except all text documents are really the same).

For what it's worth, we could potentially fix this in LanguageClient-neovim by grouping the TextDocumentEdits by text document URI, but I feel like this is just a misinterpretation of the specification.

[memoryruins]

I'm also able to recreate the issue with coc-rust-analyzer --

rust-analyzer 017331a

[lnicola]

CC #4831.

[matklad]

Hm, yup, that's definitely a bug, and I think even the design one. The fix is to change find_usages API to return references, groupped by the file:

https://github.com/rust-analyzer/rust-analyzer/blob/83a16e825da2767aaee1d62447eb94f4d7de8881/crates/ra_ide_db/src/search.rs#L181-L185

Ie, I'd imagine something like:

struct FileReferences {
  file_id: FIleId,
  refs: Vec<FileReference> // stores only `TextRange`
}

After this refactor, changing all the call-sites should should automagicaly fix all the issues (I belive we have a similar problem in the new extract enum variant assist).

[kjeremy]

I don't think this is quite true anymore. SourceChange still traffics in SourceFileEdits. Maybe SourceChange should keep it's edits in a map by FileId as well.

[koopa1338]

Im not sure if I have a similar issue. I'm using neovim lsp and tried to rename a variable that has multiple occurences in the same file but getting an error like buffer <filepath> newer than edits. I also tried this with a python language server, where it works as expected.
I've looked into the response from the servers:

• python groups the edits in one documentChange by file uri and version
• rust-analyzer has individual documentChanges per occurence with the same version

I've changed many settings in my vim config but with the same results and as it works with other languages, this might seem an issue in the rust-analyzer.

used:

• NVIM v0.5.0-681-g7ba28b1ae
• rust-analyzer latest commit

[sharksforarms]

Im not sure if I have a similar issue. I'm using neovim lsp and tried to rename a variable that has multiple occurences in the same file but getting an error like buffer <filepath> newer than edits.

@koopa1338, see neovim/neovim#12970

[Xuyuanp]

Here is my workaround
https://github.com/Xuyuanp/vimrc/blob/f322500c190aed620f697a9b2b8ed8251805abe5/lua/dotvim/lsp/callbacks.lua#L71

[martskins]

It has been a while since the suggestion for how to fix this was given, do you still think that's the way to go here?

[matklad]

@martskins yup, I still think that it makes sense to first refactor the reference search API to return results grouped per file. The relevatn entry point is FindUsages::all method now.

[matklad]

Another thing which needs fixing after the underlying issue is resolved: https://github.com/rust-analyzer/rust-analyzer/pull/7032/files#diff-a7e1e771e911237bb893e1b0f5e0f2c2a856b54ca06f95ef0818a922f1a8b5ebR266