Skip to content

/rust

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

Inferred types should be checked for privacy violations #30476

Closed
petrochenkov opened this Issue Dec 19, 2015 · 0 comments

Comments

Assignees

@petrochenkov petrochenkov

@jseyfried jseyfried

Labels
A-typesystem
Projects
None yet
Milestone
No milestone
3 participants
@petrochenkov @steveklabnik @jseyfried
@petrochenkov
Copy link
Contributor

petrochenkov commented Dec 19, 2015

In this example:

trait Arr0 {
    fn arr0_secret(&self);
}
trait TyParam {
    fn ty_param_secret(&self);
}

mod m {
    struct Priv;

    impl ::Arr0 for [Priv; 0] { fn arr0_secret(&self) {} }
    impl ::TyParam for Option<Priv> { fn ty_param_secret(&self) {} }
}

fn main() {
    [].arr0_secret();
    None.ty_param_secret();
}

[] and None are inferred to be values of private types [Priv; 0] and Option<Priv>.
(Some more examples can be found in https://internals.rust-lang.org/t/limits-of-type-inference-smartness/2919)

Privacy checker and "private-in-public" checker try hard to ensure the guarantee, that values of private types can't be obtained outside of their modules. If inferred types are checked for privacy, then this guarantee can actually be made strict.
One reason why this guarantee is useful, is because link time visibility is based on the language privacy, so it gives a way to reduce the number of methods visible from our libraries to outside.

@petrochenkov petrochenkov referenced this issue Dec 20, 2015

Merged

privacy: Rewrite VisiblePrivateTypesVisitor #29973

petrochenkov referenced this issue in jseyfried/rfcs Feb 17, 2016

@jseyfried
Start writing the nameable_interfaces RFC
a23a5c9

@deadalusai deadalusai referenced this issue May 7, 2016

Closed

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

@steveklabnik steveklabnik added the A-typesystem label Jun 6, 2016

@petrochenkov petrochenkov referenced this issue Nov 10, 2016

Open

Tracking issue for `private_in_public` compatibility lint. #34537

3 of 5 tasks complete

@jseyfried jseyfried self-assigned this Dec 22, 2016

@jseyfried jseyfried referenced this issue Dec 22, 2016

Merged

Use `DefId`s instead of `NodeId`s for `pub(restricted)` visibilities #38490

@jseyfried jseyfried referenced this issue Feb 7, 2017

Open

Tracking issue: declarative macros 2.0 #39412

9 of 19 tasks complete

@petrochenkov petrochenkov self-assigned this Feb 19, 2017

@jseyfried jseyfried referenced this issue Mar 31, 2017

Merged

Initial implementation of declarative macros 2.0 #40847

@petrochenkov petrochenkov referenced this issue May 20, 2017

Merged

Check types for privacy #42125

bors added a commit that referenced this issue Jun 5, 2017

@bors
Auto merge of #42125 - petrochenkov:privty, r=<try> 
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
Loading status checks…
ab4661d

bors added a commit that referenced this issue Jun 19, 2017

@bors
Auto merge of #42125 - petrochenkov:privty, r=alexcrichton 
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
Loading status checks…
3639099

bors added a commit that referenced this issue Jul 7, 2017

@bors
Auto merge of #42125 - petrochenkov:privty, r=nikomatsakis 
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
Loading status checks…
b80b659

@bors bors closed this in #42125 Jul 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.