Skip to content
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

ensure renames happen after edit #15940

Merged
merged 1 commit into from Nov 21, 2023
Merged

Conversation

pascalkuthe
Copy link
Contributor

This is a bugfix for an issue I fould while working on helix. Rust-analyzer currently always sends any filesystem edits (rename/file creation) before any other edits. When renaming a file that is also being edited that would mean that the edit would be discarded and therefore an incomplete/incorrect refactor (or even cause the creation of a new file in helix altough that is probably a pub on our side).

Example:

  • create a module: mod foo containing a pub sturct Bar;
  • reexport the struct uneder a different name in the foo module using a fully qualified path: pub use crate::foo::Bar as Bar2.
  • rename the foo module to foo2 using rust-analyzer
  • obsereve that the path is not correctly updated (rust-analyer first sends a rename foo.rs to foo2.rs and then edits foo.rs after)

This PR fixes that issue by simply executing all rename operations after all edit operations (while still executing file creation operations first). I also added a testcase similar to the example above.

Relevent excerpt from the LSP standard:

Since version 3.13.0 a workspace edit can contain resource operations (create, delete or rename files and folders) as well. If resource operations are present clients need to execute the operations in the order in which they are provided. So a workspace edit for example can consist of the following two changes: (1) create file a.txt and (2) a text document edit which insert text into file a.txt. An invalid sequence (e.g. (1) delete file a.txt and (2) insert text into file a.txt) will cause failure of the operation. How the client recovers from the failure is described by the client capability: workspace.workspaceEdit.failureHandling

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 20, 2023
@Veykril
Copy link
Member

Veykril commented Nov 21, 2023

Nice catch, thanks!
@bors r+

@bors
Copy link
Collaborator

bors commented Nov 21, 2023

📌 Commit 0647b64 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Nov 21, 2023

⌛ Testing commit 0647b64 with merge 2e7e8cc...

@bors
Copy link
Collaborator

bors commented Nov 21, 2023

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 2e7e8cc to master...

@bors bors merged commit 2e7e8cc into rust-lang:master Nov 21, 2023
10 checks passed
@pascalkuthe pascalkuthe deleted the fix_rename branch November 21, 2023 11:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants