Rust 1.19 regression, 0.1.8, variant is private and cannot be reexported in pub glob

[brson]

https://github.com/rust-locale/rust-locale

commit bd222a46a1ca2326220b6a071a6c712afe97f19f
Author: Ben S <ogham@bsago.me>
Date:   Thu Apr 23 07:59:28 2015 +0100

    Remove #[deprecated] attributes

brian@ip-10-145-43-250:/mnt2/dev⟫ rustc +nightly -Vv
rustc 1.19.0-nightly (0418fa9d3 2017-06-04)
binary: rustc
commit-hash: 0418fa9d382a47d782cc1e195c14573be9c32095
commit-date: 2017-06-04
host: x86_64-unknown-linux-gnu
release: 1.19.0-nightly
LLVM version: 4.0

error: variant `_NL_CTYPE_OUTDIGIT2_MB` is private, and cannot be reexported, consider declaring its enum as `pub`
   --> src/linux/langinfo.rs:135:9
    |
135 | pub use self::CTypeStringItems::*;
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: variant `_NL_TIME_WEEK_NDAYS` is private, and cannot be reexported, consider declaring its enum as `pub`
   --> src/linux/langinfo.rs:415:9
    |
415 | pub use self::ByteItems::*;
    |         ^^^^^^^^^^^^^^^^^^^

[brson]

Probably from #42136

What exactly is going on here that is broken? It looks like they might be reexporting private variants, but I don't see a lint in the linked PR that looks exactly like that.

[brson]

cargobomb sees this in 5-6 crates revisions, some in wide use like mustache and nickel.

[brson]

nickel inherits the breakage from mustache.

cc @erickt @cburgdorf

[brson]

Quite a few crates infected by mustache here.

[petrochenkov]

@brson
This is a subset of private_in_public lint (#34537), cc'd from #42136. This was a warning since 2015 and even then locale was the only regression for the "private variant reexport" case.
The problem is that the 0.2.x branch of locale is not developed and was last updated on Feb 15, 2016.
I asked @jan-hudec to publish a new version and locale-0.2.2 was published recently, it includes the fix.
Dependent crates have to be updated. I'm not sure why all these dependent regression didn't show up in #42136 crater run. I sent patches to everything that appeared there (I can send more, but I need to know what crates are affected).

[nikomatsakis]

@petrochenkov did we consider exempting the private variants from the *? I guess that would be somewhat inconsistent.

[brson]

@petrochenkov I've assigned you.

[petrochenkov]

@nikomatsakis
If I understand correctly you are suggesting this

enum E {
    V,
    U,
}

pub use E::*; // OK, but exports nothing, should be reported as unused import

which is quite reasonable and consistent with module behavior

mod m {
    struct A;
    struct B;
}

pub use m::*; // OK, but exports nothing, should be reported as unused import but doesn't currently

There are two issues with this

• This doesn't fix locale-0.2.1, because it relies on pub use E::*; actually reexporting something. Even if this is permitted in resolve it's still a type privacy violation that will be caught by Check types for privacy #42125 (you can actually see locale-0.2.1 in the crater report there).
• This may be more surprising than the current early error - "wait, I've just reexported these variants, where are they?", but probably not too surprising, because glob reexport from modules behave in the same way.

As a result, I'm mildly in favor of turning this error into "unused import" warning, but I't won't help with locale-0.2.1 which is legitimately broken.

[nikomatsakis]

@petrochenkov

Yes, I think you understood me.

This doesn't fix locale-0.2.1, because it relies on pub use E::*; actually reexporting something.

In other words, it really wants the enum to be public, but it's not?

because glob reexport from modules behave in the same way.

This was the precedent I was thinking of, yeah. It's sort of "as if" the enum were a mini-module -- but the analogy doesn't quite work, since if the items were truly acting like private members, then E::V wouldn't work.

[petrochenkov]

@nikomatsakis

In other words, it really wants the enum to be public, but it's not?

Yes.