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

Private variants can be publicly reexported #30055

Closed
petrochenkov opened this issue Nov 25, 2015 · 0 comments
Closed

Private variants can be publicly reexported #30055

petrochenkov opened this issue Nov 25, 2015 · 0 comments
Labels
A-resolve Area: Name resolution

Comments

@petrochenkov
Copy link
Contributor

This snippet compiles, but it shouldn't, because the variants V1 and V2 belong to private enums and private things can't normally be publicly reexported.

enum E1 { V1 }
enum E2 { V2 }

pub use E1::V1;
pub use E2::*;

fn main() {}

Reproduces on stable/beta/nightly.
The E1::V1 case is fixed in #29973, E2::* is not fixed is fixed in #29973 as well .

@Aatch Aatch added I-wrong A-resolve Area: Name resolution labels Nov 27, 2015
bors added a commit that referenced this issue Dec 18, 2015
Some notes:
This patch enforces the rules from [RFC 136](https://github.com/rust-lang/rfcs/blob/master/text/0136-no-privates-in-public.md) and makes "private in public" a module-level concept and not crate-level. Only `pub` annotations are used by the new algorithm, crate-level exported node set produced by `EmbargoVisitor` is not used. The error messages are tweaked accordingly and don't use the word "exported" to avoid confusing people (#29668).

The old algorithm tried to be extra smart with impls, but it mostly led to unpredictable behavior and bugs like #28325.
The new algorithm tries to be as simple as possible - an impl is considered public iff its type is public and its trait is public (if presents).
A type or trait is considered public if all its components are public, [complications](https://internals.rust-lang.org/t/limits-of-type-inference-smartness/2919) with private types leaking to other crates/modules through trait impls and type inference are deliberately ignored so far.

The new algorithm is not recursive and uses the nice new facility `Crate::visit_all_items`!

Obsolete pre-1.0 feature `visible_private_types` is removed.

This is a [breaking-change].
The two main vectors of breakage are type aliases (#28450) and impls (#28325).
I need some statistics from a crater run (cc @alexcrichton) to decide on the breakage mitigation strategy.
UPDATE: All the new errors are reported as warnings controlled by a lint `private_in_public` and lint group `future_incompatible`, but the intent is to make them hard errors eventually.

Closes #28325
Closes #28450
Closes #29524
Closes #29627
Closes #29668
Closes #30055

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name resolution
Projects
None yet
Development

No branches or pull requests

2 participants