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

Exhaustiveness should ignore non-constructable patterns #15940

Closed
brendanzab opened this issue Jul 24, 2014 · 3 comments
Closed

Exhaustiveness should ignore non-constructable patterns #15940

brendanzab opened this issue Jul 24, 2014 · 3 comments

Comments

@brendanzab
Copy link
Member

Currently this does not compile:

enum Void {}

fn main() {
    let x = None::<Void>;
    match x {
        None => println!("hi"),
    }
}
<anon>:5:5: 7:6 error: non-exhaustive patterns: `Some(_)` not covered [E0004]
<anon>:5     match x {
<anon>:6         None => println!("hi"),
<anon>:7     }

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.

@huonw
Copy link
Member

huonw commented Jul 24, 2014

This is possibly a dupe of #12609.

@ghost
Copy link

ghost commented Jul 26, 2014

@huonw It definitely is. I think we could close it.

@alexcrichton
Copy link
Member

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants