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.

Sign up for GitHub

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

Jump to bottom

"Private" impl functions can leak out of a module when defined on a public type #33479

Closed
deadalusai opened this issue May 7, 2016 · 2 comments
Closed

"Private" impl functions can leak out of a module when defined on a public type #33479

deadalusai opened this issue May 7, 2016 · 2 comments
Assignees
@petrochenkov
Labels
A-type-system Area: Type system

Comments

@deadalusai
Copy link

"Private" impl functions can leak out of a module when defined on a public type. This can allow private types to appear as part of a modules' public interface.

Example on playground: http://is.gd/aGx2MV

In this example, the type Private leaks out of the_module via the impl Public<Private> impl block. It looks like all functions in that block should be inferred to be private?

Reddit discussion
@deadalusai
Copy link
Author

This issue seems similar.

@petrochenkov
Copy link
Contributor

petrochenkov commented May 7, 2016 •
edited
Loading

Yep, incarnation of #30476 (although the example is sufficiently different from those given in #30476), one more example of type inference being too smart.

Private-in-public checker assumes that the type Public<Private> is private and therefore its impls are private, because you can't name it or construct its values outside of its module without using Private.
However, type inference is able to infer private type parameters in some cases and it's not something generally fixable with private-in-public checker alone.

@petrochenkov petrochenkov self-assigned this Feb 19, 2017
@petrochenkov petrochenkov added the A-type-system Area: Type system label Feb 19, 2017
@petrochenkov petrochenkov mentioned this issue May 20, 2017
Merged
bors added a commit that referenced this issue Jun 5, 2017
@bors
Auto merge of #42125 - petrochenkov:privty, r=<try>
ab4661d 
Check types for privacy

This PR implements late post factum checking of type privacy, as opposed to early preventive "private-in-public" checking.
This will allow to turn private-in-public checks into a lint and make them more heuristic-based, and more aligned with what people may expect (e.g. reachability-based behavior).

Types are privacy-checked if they are written explicitly, and also if they are inferred as expression or pattern types.
This PR checks "semantic" types and does it unhygienically, this significantly restricts what macros 2.0 (as implemented in #40847) can do (sorry @jseyfried) - they still can use private *names*, but can't use private *types*.
This is the most conservative solution, but hopefully it's temporary and can be relaxed in the future, probably using macro contexts of expression/pattern spans.

Traits are also checked in preparation for [trait aliases](#41517), which will be able to leak private traits, and macros 2.0 which will be able to leak pretty much anything.

This is a [breaking-change], but the code that is not contrived and can be broken by this patch should be guarded by `private_in_public` lint. [Previous crater run](#34537 (comment)) discovered a few abandoned crates that weren't updated since `private_in_public` has been introduced in 2015.

cc #34537 https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504
Fixes #30476
Fixes #33479

cc @nikomatsakis
r? @eddyb
bors added a commit that referenced this issue Jul 7, 2017
@bors
Auto merge of #42125 - petrochenkov:privty, r=nikomatsakis
b80b659 
Check types for privacy

This PR implements late post factum checking of type privacy, as opposed to early preventive "private-in-public" checking.
This will allow to turn private-in-public checks into a lint and make them more heuristic-based, and more aligned with what people may expect (e.g. reachability-based behavior).

Types are privacy-checked if they are written explicitly, and also if they are inferred as expression or pattern types.
This PR checks "semantic" types and does it unhygienically, this significantly restricts what macros 2.0 (as implemented in #40847) can do (sorry @jseyfried) - they still can use private *names*, but can't use private *types*.
This is the most conservative solution, but hopefully it's temporary and can be relaxed in the future, probably using macro contexts of expression/pattern spans.

Traits are also checked in preparation for [trait aliases](#41517), which will be able to leak private traits, and macros 2.0 which will be able to leak pretty much anything.

This is a [breaking-change], but the code that is not contrived and can be broken by this patch should be guarded by `private_in_public` lint. [Previous crater run](#34537 (comment)) discovered a few abandoned crates that weren't updated since `private_in_public` has been introduced in 2015.

cc #34537 https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504
Fixes #30476
Fixes #33479

cc @nikomatsakis
r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@petrochenkov petrochenkov

Labels
A-type-system Area: Type system
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@deadalusai @petrochenkov