Tracking issue for visible_private_types feature
#29627
Labels
B-unstable
Blocker: Implemented in the nightly compiler and unstable.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
aturon
added
T-lang
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
The
visible_private_typesfeature allows exposing private types in public signatures (in contravention of RFC 136). This feature should probably be removed.The text was updated successfully, but these errors were encountered: