-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Exhaustiveness should ignore non-constructable patterns #15940
Comments
This is possibly a dupe of #12609. |
@huonw It definitely is. I think we could close it. |
Closing as a dupe. |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 27, 2023
ensure renames happen after edit 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently this does not compile:
playpen
I contend that because
Some::<Void>
is impossible to construct (Void
is an uninhabited enum), exhaustiveness should not require it to be matched against.The text was updated successfully, but these errors were encountered: