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

[nightly regression] E0639 + adding #[non_exhaustive] to io::ErrorKind is a breaking change #53549

Closed
durka opened this issue Aug 21, 2018 · 5 comments · Fixed by #53721
Closed
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@durka
Copy link
Contributor

durka commented Aug 21, 2018

In stable and beta, you can write ErrorKind::Other {}, but in nightly this triggers E0639: cannot create non-exhaustive variant using struct expression. (As an aside, that error message should be rephrased and examples added to --explain.)

This is either a bug with #[non_exhaustive], or it means that the attribute can't be applied to public enums without creating a breaking change.

@durka
Copy link
Contributor Author

durka commented Aug 21, 2018

I noticed this due to Travis tests of this code here. This is obviously(?) not a serious crate, but illustrates that this restriction is problematic for macros. That line expands to

    Err(_) => Err(io::Error::new(io::ErrorKind::Other{}, "invalid UTF-8"))

durka added a commit to durka/macrolisp that referenced this issue Aug 21, 2018
@Havvy
Copy link
Contributor

Havvy commented Aug 21, 2018

This is a bug. Adding #[non_exhaustive] to an enum should not prevent the creation of enum variants, although adding the attribute to an enum variant explicitly allows for that. Especially since ErrorKind::Other without the {} is still valid.

@Havvy
Copy link
Contributor

Havvy commented Aug 21, 2018

Minimal example.

Defining crate:

#[non_exhaustive]
pub enum NeEnum {
    Variant
}

Using crate:

fn make_ne_enum() -> NeEnum {
    // works
    NeEnum::Variant
}

fn make_ne_enum_2() -> NeEnum {
    // fails
    NeEnum::Variant{}
}

@kennytm kennytm added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. C-bug Category: This is a bug. labels Aug 21, 2018
@arielb1
Copy link
Contributor

arielb1 commented Aug 26, 2018

I have a fix

arielb1 added a commit to arielb1/rust that referenced this issue Aug 26, 2018
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.

Fixes rust-lang#53549.
@pnkfelix
Copy link
Member

visiting for triage. P-high. (Fixed by #53721 in any case)

@pnkfelix pnkfelix added P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 30, 2018
bors added a commit that referenced this issue Sep 6, 2018
fix `is_non_exhaustive` confusion between structs and enums

Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.

Fixes #53549.

r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. 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.

5 participants