Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2013-10-07 15:01:47 -05:00
|
|
|
#[feature(globs)];
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
#[no_std]; // makes debugging this test *a lot* easier (during resolve)
|
|
|
|
|
|
|
|
mod bar {
|
|
|
|
// shouln't bring in too much
|
|
|
|
pub use self::glob::*;
|
|
|
|
|
|
|
|
// can't publicly re-export private items
|
|
|
|
pub use self::baz::{foo, bar};
|
|
|
|
//~^ ERROR: function `bar` is private
|
|
|
|
|
|
|
|
pub use self::private::ppriv;
|
|
|
|
//~^ ERROR: function `ppriv` is private
|
|
|
|
|
|
|
|
pub struct A;
|
|
|
|
impl A {
|
|
|
|
pub fn foo() {}
|
|
|
|
fn bar() {}
|
|
|
|
|
|
|
|
pub fn foo2(&self) {}
|
|
|
|
fn bar2(&self) {}
|
|
|
|
}
|
|
|
|
|
2013-11-20 17:15:34 -06:00
|
|
|
trait B {
|
|
|
|
fn foo() -> Self;
|
|
|
|
}
|
|
|
|
|
|
|
|
impl B for int { fn foo() -> int { 3 } }
|
|
|
|
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
pub enum Enum {
|
|
|
|
priv Priv,
|
|
|
|
Pub
|
|
|
|
}
|
|
|
|
|
|
|
|
mod baz {
|
|
|
|
pub struct A;
|
|
|
|
impl A {
|
|
|
|
pub fn foo() {}
|
|
|
|
fn bar() {}
|
|
|
|
|
|
|
|
pub fn foo2(&self) {}
|
|
|
|
fn bar2(&self) {}
|
|
|
|
}
|
|
|
|
|
|
|
|
// both of these are re-exported by `bar`, but only one should be
|
|
|
|
// validly re-exported
|
|
|
|
pub fn foo() {}
|
|
|
|
fn bar() {}
|
|
|
|
}
|
|
|
|
|
|
|
|
extern {
|
|
|
|
fn epriv();
|
|
|
|
pub fn epub();
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test() {
|
|
|
|
self::Priv;
|
|
|
|
self::Pub;
|
|
|
|
unsafe {
|
|
|
|
epriv();
|
|
|
|
epub();
|
|
|
|
}
|
|
|
|
self::baz::A;
|
|
|
|
self::baz::A::foo();
|
|
|
|
self::baz::A::bar(); //~ ERROR: method `bar` is private
|
|
|
|
self::baz::A.foo2();
|
|
|
|
self::baz::A.bar2(); //~ ERROR: method `bar2` is private
|
|
|
|
|
|
|
|
// this used to cause an ICE in privacy traversal.
|
|
|
|
super::gpub();
|
|
|
|
}
|
|
|
|
|
|
|
|
mod glob {
|
|
|
|
pub fn gpub() {}
|
|
|
|
fn gpriv() {}
|
|
|
|
}
|
|
|
|
|
|
|
|
mod private {
|
|
|
|
fn ppriv() {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn gpub() {}
|
|
|
|
|
|
|
|
fn lol() {
|
|
|
|
bar::A;
|
|
|
|
bar::A::foo();
|
|
|
|
bar::A::bar(); //~ ERROR: method `bar` is private
|
|
|
|
bar::A.foo2();
|
|
|
|
bar::A.bar2(); //~ ERROR: method `bar2` is private
|
|
|
|
}
|
|
|
|
|
|
|
|
mod foo {
|
|
|
|
fn test() {
|
|
|
|
::bar::A::foo();
|
|
|
|
::bar::A::bar(); //~ ERROR: method `bar` is private
|
|
|
|
::bar::A.foo2();
|
|
|
|
::bar::A.bar2(); //~ ERROR: method `bar2` is private
|
2013-10-14 17:12:40 -05:00
|
|
|
::bar::baz::A::foo(); //~ ERROR: method `foo` is inaccessible
|
|
|
|
//~^ NOTE: module `baz` is private
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
::bar::baz::A::bar(); //~ ERROR: method `bar` is private
|
2013-10-14 17:12:40 -05:00
|
|
|
::bar::baz::A.foo2(); //~ ERROR: struct `A` is inaccessible
|
|
|
|
//~^ NOTE: module `baz` is private
|
|
|
|
::bar::baz::A.bar2(); //~ ERROR: struct `A` is inaccessible
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
//~^ ERROR: method `bar2` is private
|
2013-10-14 17:12:40 -05:00
|
|
|
//~^^ NOTE: module `baz` is private
|
2013-11-20 17:15:34 -06:00
|
|
|
|
|
|
|
let _: int =
|
|
|
|
::bar::B::foo(); //~ ERROR: method `foo` is inaccessible
|
|
|
|
//~^ NOTE: trait `B` is private
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
::lol();
|
|
|
|
|
|
|
|
::bar::Priv; //~ ERROR: variant `Priv` is private
|
|
|
|
::bar::Pub;
|
|
|
|
|
|
|
|
unsafe {
|
|
|
|
::bar::epriv(); //~ ERROR: function `epriv` is private
|
|
|
|
::bar::epub();
|
|
|
|
}
|
|
|
|
|
|
|
|
::bar::foo();
|
|
|
|
::bar::bar();
|
|
|
|
|
|
|
|
::bar::gpub();
|
|
|
|
|
2013-10-14 17:12:40 -05:00
|
|
|
::bar::baz::foo(); //~ ERROR: function `foo` is inaccessible
|
|
|
|
//~^ NOTE: module `baz` is private
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
::bar::baz::bar(); //~ ERROR: function `bar` is private
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test2() {
|
|
|
|
use bar::baz::{foo, bar};
|
2013-10-14 17:12:40 -05:00
|
|
|
//~^ ERROR: function `foo` is inaccessible
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
//~^^ ERROR: function `bar` is private
|
|
|
|
foo();
|
|
|
|
bar();
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test3() {
|
|
|
|
use bar::baz;
|
|
|
|
//~^ ERROR: module `baz` is private
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test4() {
|
|
|
|
use bar::{foo, bar};
|
|
|
|
foo();
|
|
|
|
bar();
|
|
|
|
}
|
|
|
|
|
|
|
|
fn test5() {
|
|
|
|
use bar;
|
|
|
|
bar::foo();
|
|
|
|
bar::bar();
|
|
|
|
}
|
2013-12-08 13:25:35 -06:00
|
|
|
|
|
|
|
impl ::bar::B for f32 { fn foo() -> f32 { 1.0 } }
|
|
|
|
//~^ ERROR: trait `B` is private
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
pub mod mytest {
|
|
|
|
// Even though the inner `A` struct is a publicly exported item (usable from
|
|
|
|
// external crates through `foo::foo`, it should not be accessible through
|
|
|
|
// its definition path (which has the private `i` module).
|
|
|
|
use self::foo::foo;
|
2013-10-14 17:12:40 -05:00
|
|
|
use self::foo::i::A; //~ ERROR: type `A` is inaccessible
|
|
|
|
//~^ NOTE: module `i` is private
|
Extract privacy checking from name resolution
This commit is the culmination of my recent effort to refine Rust's notion of
privacy and visibility among crates. The major goals of this commit were to
remove privacy checking from resolve for the sake of sane error messages, and to
attempt a much more rigid and well-tested implementation of visibility
throughout rust. The implemented rules for name visibility are:
1. Everything pub from the root namespace is visible to anyone
2. You may access any private item of your ancestors.
"Accessing a private item" depends on what the item is, so for a function this
means that you can call it, but for a module it means that you can look inside
of it. Once you look inside a private module, any accessed item must be "pub
from the root" where the new root is the private module that you looked into.
These rules required some more analysis results to get propagated from trans to
privacy in the form of a few hash tables.
I added a new test in which my goal was to showcase all of the privacy nuances
of the language, and I hope to place any new bugs into this file to prevent
regressions.
Overall, I was unable to completely remove the notion of privacy from resolve.
One use of privacy is for dealing with glob imports. Essentially a glob import
can only import *public* items from the destination, and because this must be
done at namespace resolution time, resolve must maintain the notion of "what
items are public in a module". There are some sad approximations of privacy, but
I unfortunately can't see clear methods to extract them outside.
The other use case of privacy in resolve now is one that must stick around
regardless of glob imports. When dealing with privacy, checking a private path
needs to know "what the last private thing was" when looking at a path. Resolve
is the only compiler pass which knows the answer to this question, so it
maintains the answer on a per-path resolution basis (works similarly to the
def_map generated).
Closes #8215
2013-10-05 16:37:39 -05:00
|
|
|
|
|
|
|
pub mod foo {
|
|
|
|
pub use foo = self::i::A;
|
|
|
|
|
|
|
|
mod i {
|
|
|
|
pub struct A;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[start] fn main(_: int, _: **u8) -> int { 3 }
|