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

E0005; should all constructors be listed? #56379

Closed
Centril opened this issue Nov 30, 2018 · 6 comments · Fixed by #80104
Closed

E0005; should all constructors be listed? #56379

Centril opened this issue Nov 30, 2018 · 6 comments · Fixed by #80104
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Nov 30, 2018

See #56362 (comment) for context.

cc @estebank @petrochenkov @varkor

@Centril Centril added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 30, 2018
@estebank
Copy link
Contributor

Maybe we could do that with an upper bound, as having more than ~3 listed ranges will get really noisy. Imagine if you had a check for every other integer in u16, you'd have 32K ranges! I'd be fine with it as long as this is handled gracefully.

It'll also be nice to mention when a range between two values involves std::{integer}::MAX or MIN.

@Centril
Copy link
Contributor Author

Centril commented Nov 30, 2018

@estebank Yeah an upper bound makes sense.

@varkor
Copy link
Member

varkor commented Nov 30, 2018

It'll also be nice to mention when a range between two values involves std::{integer}::MAX or MIN.

Yeah, this was a case I was thinking about too — it'll probably be fairly common case, so it'd be good to handle sensibly.

Edit: I've filed #56393 for this specific suggestion.

@estebank
Copy link
Contributor

@Centril is there still work left to do on this front?

@varkor
Copy link
Member

varkor commented Oct 10, 2019

The match algorithm still short-circuits and reports only the first unencountered constructor in some cases. You can see this in some of the test cases for #65160, for instance.

@crlf0710 crlf0710 added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jun 11, 2020
@Nadrieril
Copy link
Member

Nadrieril commented Nov 22, 2020

Couldn't find an example with missing integer ranges like the one mentioned in the OP; I suspect we've fixed those. Here's a different one (play):

enum Foo {
    A(bool),
    B(bool),
    C(bool),
}
fn main() {
    match Foo::A(true) {
        Foo::A(true) => {},
        Foo::B(true) => {},
        Foo::C(true) => {},
    }
}

This only errors about A(false) not being covered.

I'm adding my favorite label so I can find this later.
@rustbot modify labels: +A-exhaustiveness-checking

@rustbot rustbot added the A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns label Nov 22, 2020
@bors bors closed this as completed in 1f5bc17 Dec 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-exhaustiveness-checking Relating to exhaustiveness / usefulness checking of patterns C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants