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.

[erickt]

@brson unfortunately I don't have commit access to the current mustache repository. I've asked for access in nickel-org/rust-mustache#47.

[nikomatsakis]

What is the current status here? I'm having second thoughts about accepting this code, given that the analogy to a module doesn't really hold up -- can we patch up the crates in question?

[petrochenkov]

@nikomatsakis
locale is already patched and I don't know what else needs to be fixed.
@brson mentioned mustache and nickel, but they both do not depend on locale, maybe only older versions are affected?
ping @erickt

[nikomatsakis]

@petrochenkov ok -- so -- is any further action needed here then? I guess we just want to see whether older versions of mustache and nickel need some sort of update?

[petrochenkov]

@nikomatsakis
I believe no action is required from our side.

I guess we just want to see whether older versions of mustache and nickel need some sort of update?

Most of mustache versions are not tagged, there are also no version branches to send PRs to, and @erickt , who has publishing rights, is silent. What can we do? Wash our hands, I guess.

[nikomatsakis]

OK, I am going to close as "changed due to bug fix" then. I added the relnotes tag, because this change potentially affects end users. Specifically, code like this used to compile, even though it is re-exporting private variants (Bar, Baz) as public:

enum Foo { Bar, Baz }
pub use self::Foo::Bar;

We now correctly report a compilation error.

[brson]

@petrochenkov it is an older mustache but one that is a dependency of many crates.