Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # 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