rust/src/librustc/middle/resolve.rs

5596 lines
223 KiB
Rust
Raw Normal View History

// Copyright 2012-2014 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.
use driver::session::Session;
use metadata::csearch;
use metadata::decoder::{DefLike, DlDef, DlField, DlImpl};
2012-09-04 13:54:36 -05:00
use middle::lang_items::LanguageItems;
2014-01-09 20:29:45 -06:00
use middle::lint::{UnnecessaryQualification, UnusedImports};
2013-03-26 15:38:07 -05:00
use middle::pat_util::pat_bindings;
use syntax::ast::*;
2013-05-21 20:24:42 -05:00
use syntax::ast;
2013-09-05 16:15:00 -05:00
use syntax::ast_util::{def_id_of_def, local_def, mtwt_resolve};
2012-09-04 13:54:36 -05:00
use syntax::ast_util::{path_to_ident, walk_pat, trait_method_to_ty_method};
2014-01-31 14:25:11 -06:00
use syntax::parse::token::{IdentInterner, special_idents};
2013-05-14 19:27:27 -05:00
use syntax::parse::token;
2013-03-26 15:38:07 -05:00
use syntax::print::pprust::path_to_str;
use syntax::codemap::{Span, DUMMY_SP, Pos};
use syntax::opt_vec::OptVec;
use syntax::visit;
use syntax::visit::Visitor;
2013-12-20 23:14:25 -06:00
use std::cell::{Cell, RefCell};
use std::uint;
use std::hashmap::{HashMap, HashSet};
use std::mem::replace;
// Definition mapping
pub type DefMap = @RefCell<HashMap<NodeId,Def>>;
2013-10-02 07:33:01 -05:00
struct binding_info {
span: Span,
binding_mode: BindingMode,
}
// Map from the name in a pattern to its binding mode.
2013-10-02 07:33:01 -05:00
type BindingMap = HashMap<Name,binding_info>;
// Trait method resolution
2013-12-22 16:03:39 -06:00
pub type TraitMap = HashMap<NodeId,@RefCell<~[DefId]>>;
// This is the replacement export map. It maps a module to all of the exports
// within.
2013-12-20 23:14:25 -06:00
pub type ExportMap2 = @RefCell<HashMap<NodeId, ~[Export2]>>;
pub struct Export2 {
2014-01-31 14:25:11 -06:00
name: ~str, // The name of the target.
def_id: DefId, // The definition of the target.
}
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
// This set contains all exported definitions from external crates. The set does
// not contain any entries from local crates.
pub type ExternalExports = HashSet<DefId>;
// FIXME: dox
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 type LastPrivateMap = HashMap<NodeId, LastPrivate>;
pub enum LastPrivate {
AllPublic,
DependsOn(DefId),
}
impl LastPrivate {
fn or(self, other: LastPrivate) -> LastPrivate {
match (self, other) {
(me, AllPublic) => me,
(_, other) => other,
}
}
}
#[deriving(Eq)]
2013-10-02 07:33:01 -05:00
enum PatternBindingMode {
RefutableMode,
LocalIrrefutableMode,
ArgumentIrrefutableMode,
}
#[deriving(Eq)]
2013-10-02 07:33:01 -05:00
enum Namespace {
TypeNS,
ValueNS
}
#[deriving(Eq)]
2013-10-02 07:33:01 -05:00
enum NamespaceError {
NoError,
ModuleError,
TypeError,
ValueError
}
2012-11-29 16:43:33 -06:00
/// A NamespaceResult represents the result of resolving an import in
/// a particular namespace. The result is either definitely-resolved,
/// definitely- unresolved, or unknown.
2013-10-02 07:33:01 -05:00
enum NamespaceResult {
/// Means that resolve hasn't gathered enough information yet to determine
/// whether the name is bound in this namespace. (That is, it hasn't
/// resolved all `use` directives yet.)
UnknownResult,
2012-11-29 16:43:33 -06:00
/// Means that resolve has determined that the name is definitely
/// not bound in the namespace.
UnboundResult,
/// Means that resolve has determined that the name is bound in the Module
/// argument, and specified by the NameBindings argument.
2013-12-21 16:20:57 -06:00
BoundResult(@Module, @NameBindings)
}
impl NamespaceResult {
2013-10-02 07:33:01 -05:00
fn is_unknown(&self) -> bool {
2013-02-22 00:41:37 -06:00
match *self {
2012-08-27 18:26:35 -05:00
UnknownResult => true,
_ => false
}
}
}
2013-10-02 07:33:01 -05:00
enum NameDefinition {
NoNameDefinition, //< The name was unbound.
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
ChildNameDefinition(Def, LastPrivate), //< The name identifies an immediate child.
ImportNameDefinition(Def, LastPrivate) //< The name identifies an import.
}
impl Visitor<()> for Resolver {
fn visit_item(&mut self, item: &Item, _: ()) {
self.resolve_item(item);
}
2014-01-06 06:00:46 -06:00
fn visit_arm(&mut self, arm: &Arm, _: ()) {
self.resolve_arm(arm);
}
2014-01-06 06:00:46 -06:00
fn visit_block(&mut self, block: &Block, _: ()) {
self.resolve_block(block);
}
2014-01-06 06:00:46 -06:00
fn visit_expr(&mut self, expr: &Expr, _: ()) {
self.resolve_expr(expr);
}
2014-01-06 06:00:46 -06:00
fn visit_local(&mut self, local: &Local, _: ()) {
self.resolve_local(local);
}
2014-01-06 06:00:46 -06:00
fn visit_ty(&mut self, ty: &Ty, _: ()) {
self.resolve_type(ty);
}
}
/// Contains data for specific types of import directives.
2013-10-02 07:33:01 -05:00
enum ImportDirectiveSubclass {
2013-09-01 19:50:59 -05:00
SingleImport(Ident /* target */, Ident /* source */),
GlobImport
}
/// The context that we thread through while building the reduced graph.
2013-07-02 14:47:32 -05:00
#[deriving(Clone)]
2013-10-02 07:33:01 -05:00
enum ReducedGraphParent {
2013-12-19 21:02:22 -06:00
ModuleReducedGraphParent(@Module)
}
impl ReducedGraphParent {
fn module(&self) -> @Module {
match *self {
ModuleReducedGraphParent(m) => {
m
}
}
}
}
2013-10-02 07:33:01 -05:00
enum ResolveResult<T> {
Failed, // Failed to resolve the name.
Indeterminate, // Couldn't determine due to unresolved globs.
Success(T) // Successfully resolved the import.
}
impl<T> ResolveResult<T> {
2013-10-02 07:33:01 -05:00
fn indeterminate(&self) -> bool {
2013-02-22 00:41:37 -06:00
match *self { Indeterminate => true, _ => false }
}
}
enum TypeParameters<'a> {
NoTypeParameters, //< No type parameters.
HasTypeParameters(&'a Generics, //< Type parameters.
NodeId, //< ID of the enclosing item
// The index to start numbering the type parameters at.
// This is zero if this is the outermost set of type
// parameters, or equal to the number of outer type
// parameters. For example, if we have:
//
// impl I<T> {
// fn method<U>() { ... }
// }
//
// The index at the method site will be 1, because the
// outer T had index 0.
uint,
// The kind of the rib used for type parameters.
RibKind)
}
// The rib kind controls the translation of argument or local definitions
// (`def_arg` or `def_local`) to upvars (`def_upvar`).
2013-10-02 07:33:01 -05:00
enum RibKind {
// No translation needs to be applied.
NormalRibKind,
// We passed through a function scope at the given node ID. Translate
// upvars as appropriate.
FunctionRibKind(NodeId /* func id */, NodeId /* body id */),
// We passed through an impl or trait and are now in one of its
2013-06-06 02:38:41 -05:00
// methods. Allow references to ty params that impl or trait
// binds. Disallow any other upvars (including other ty params that are
// upvars).
// parent; method itself
MethodRibKind(NodeId, MethodSort),
// We passed through a function *item* scope. Disallow upvars.
OpaqueFunctionRibKind,
// We're in a constant item. Can't refer to dynamic stuff.
ConstantItemRibKind
}
// Methods can be required or provided. Required methods only occur in traits.
2013-10-02 07:33:01 -05:00
enum MethodSort {
Required,
Provided(NodeId)
}
2013-10-02 07:33:01 -05:00
enum UseLexicalScopeFlag {
DontUseLexicalScope,
UseLexicalScope
}
2013-10-02 07:33:01 -05:00
enum SearchThroughModulesFlag {
DontSearchThroughModules,
SearchThroughModules
}
2013-10-02 07:33:01 -05:00
enum ModulePrefixResult {
NoPrefixFound,
2013-12-19 21:02:22 -06:00
PrefixFound(@Module, uint)
}
#[deriving(Eq)]
enum NameSearchType {
/// We're doing a name search in order to resolve a `use` directive.
ImportSearch,
/// We're doing a name search in order to resolve a path type, a path
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
/// expression, or a path pattern.
PathSearch,
}
2013-10-02 07:33:01 -05:00
enum BareIdentifierPatternResolution {
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
FoundStructOrEnumVariant(Def, LastPrivate),
FoundConst(Def, LastPrivate),
BareIdentifierPatternUnresolved
}
// Specifies how duplicates should be handled when adding a child item if
// another item exists with the same name in some namespace.
#[deriving(Eq)]
2013-10-02 07:33:01 -05:00
enum DuplicateCheckingMode {
ForbidDuplicateModules,
ForbidDuplicateTypes,
ForbidDuplicateValues,
ForbidDuplicateTypesAndValues,
OverwriteDuplicates
}
/// One local scope.
2013-10-02 07:33:01 -05:00
struct Rib {
2013-12-21 15:58:11 -06:00
bindings: RefCell<HashMap<Name, DefLike>>,
2012-09-06 21:40:15 -05:00
kind: RibKind,
2012-09-05 17:58:43 -05:00
}
impl Rib {
2013-10-02 07:33:01 -05:00
fn new(kind: RibKind) -> Rib {
Rib {
2013-12-21 15:58:11 -06:00
bindings: RefCell::new(HashMap::new()),
kind: kind
}
}
}
/// One import directive.
2013-10-02 07:33:01 -05:00
struct ImportDirective {
2013-09-01 19:50:59 -05:00
module_path: ~[Ident],
2012-09-06 21:40:15 -05:00
subclass: @ImportDirectiveSubclass,
span: Span,
id: NodeId,
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
is_public: bool, // see note in ImportResolution about how to use this
2012-09-05 17:58:43 -05:00
}
impl ImportDirective {
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
fn new(module_path: ~[Ident],
subclass: @ImportDirectiveSubclass,
span: Span,
id: NodeId,
is_public: bool)
-> ImportDirective {
ImportDirective {
module_path: module_path,
subclass: subclass,
span: span,
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
id: id,
is_public: is_public,
}
}
}
/// The item that an import resolves to.
#[deriving(Clone)]
2013-10-02 07:33:01 -05:00
struct Target {
2013-12-19 21:02:22 -06:00
target_module: @Module,
2013-12-21 16:20:57 -06:00
bindings: @NameBindings,
2012-09-05 17:58:43 -05:00
}
impl Target {
2013-12-21 16:20:57 -06:00
fn new(target_module: @Module, bindings: @NameBindings) -> Target {
Target {
target_module: target_module,
bindings: bindings
}
}
}
/// An ImportResolution represents a particular `use` directive.
2013-10-02 07:33:01 -05:00
struct ImportResolution {
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
/// Whether this resolution came from a `use` or a `pub use`. Note that this
/// should *not* be used whenever resolution is being performed, this is
/// only looked at for glob imports statements currently. Privacy testing
/// occurs during a later phase of compilation.
is_public: Cell<bool>,
// The number of outstanding references to this name. When this reaches
// zero, outside modules can count on the targets being correct. Before
// then, all bets are off; future imports could override this name.
outstanding_references: Cell<uint>,
/// The value that this `use` directive names, if there is one.
value_target: RefCell<Option<Target>>,
/// The source node of the `use` directive leading to the value target
/// being non-none
value_id: Cell<NodeId>,
/// The type that this `use` directive names, if there is one.
type_target: RefCell<Option<Target>>,
/// The source node of the `use` directive leading to the type target
/// being non-none
type_id: Cell<NodeId>,
}
impl ImportResolution {
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
fn new(id: NodeId, is_public: bool) -> ImportResolution {
ImportResolution {
type_id: Cell::new(id),
value_id: Cell::new(id),
outstanding_references: Cell::new(0),
value_target: RefCell::new(None),
type_target: RefCell::new(None),
is_public: Cell::new(is_public),
}
2012-09-05 17:58:43 -05:00
}
2013-10-02 07:33:01 -05:00
fn target_for_namespace(&self, namespace: Namespace)
-> Option<Target> {
match namespace {
TypeNS => return self.type_target.get(),
ValueNS => return self.value_target.get(),
}
}
fn id(&self, namespace: Namespace) -> NodeId {
match namespace {
TypeNS => self.type_id.get(),
ValueNS => self.value_id.get(),
}
}
}
/// The link from a module up to its nearest parent node.
2013-10-02 07:33:01 -05:00
enum ParentLink {
NoParentLink,
2013-12-19 21:02:22 -06:00
ModuleParentLink(@Module, Ident),
BlockParentLink(@Module, NodeId)
}
/// The type of module this is.
#[deriving(Eq)]
2013-10-02 07:33:01 -05:00
enum ModuleKind {
NormalModuleKind,
ExternModuleKind,
TraitModuleKind,
ImplModuleKind,
AnonymousModuleKind,
}
/// One node in the tree of modules.
2013-10-02 07:33:01 -05:00
struct Module {
2012-09-06 21:40:15 -05:00
parent_link: ParentLink,
def_id: Cell<Option<DefId>>,
kind: Cell<ModuleKind>,
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
is_public: bool,
2013-12-21 17:32:44 -06:00
children: RefCell<HashMap<Name, @NameBindings>>,
imports: RefCell<~[@ImportDirective]>,
// The external module children of this node that were declared with
// `extern mod`.
external_module_children: RefCell<HashMap<Name, @Module>>,
// The anonymous children of this node. Anonymous children are pseudo-
// modules that are implicitly created around items contained within
// blocks.
//
// For example, if we have this:
//
// fn f() {
// fn g() {
// ...
// }
// }
//
// There will be an anonymous module created around `g` with the ID of the
// entry block for `f`.
anonymous_children: RefCell<HashMap<NodeId,@Module>>,
// The status of resolving each import in this module.
2013-12-21 19:49:43 -06:00
import_resolutions: RefCell<HashMap<Name, @ImportResolution>>,
// The number of unresolved globs that this module exports.
glob_count: Cell<uint>,
// The index of the import we're resolving.
resolved_import_count: Cell<uint>,
// Whether this module is populated. If not populated, any attempt to
// access the children must be preceded with a
// `populate_module_if_necessary` call.
populated: Cell<bool>,
}
impl Module {
2013-10-02 07:33:01 -05:00
fn new(parent_link: ParentLink,
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
def_id: Option<DefId>,
kind: ModuleKind,
external: bool,
is_public: bool)
-> Module {
Module {
parent_link: parent_link,
def_id: Cell::new(def_id),
kind: Cell::new(kind),
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
is_public: is_public,
2013-12-21 17:32:44 -06:00
children: RefCell::new(HashMap::new()),
imports: RefCell::new(~[]),
external_module_children: RefCell::new(HashMap::new()),
anonymous_children: RefCell::new(HashMap::new()),
import_resolutions: RefCell::new(HashMap::new()),
glob_count: Cell::new(0),
resolved_import_count: Cell::new(0),
populated: Cell::new(!external),
}
2012-09-05 17:58:43 -05:00
}
2013-10-02 07:33:01 -05:00
fn all_imports_resolved(&self) -> bool {
let mut imports = self.imports.borrow_mut();
return imports.get().len() == self.resolved_import_count.get();
}
}
// Records a possibly-private type definition.
#[deriving(Clone)]
2013-10-02 07:33:01 -05:00
struct TypeNsDef {
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
is_public: bool, // see note in ImportResolution about how to use this
2013-12-19 21:02:22 -06:00
module_def: Option<@Module>,
type_def: Option<Def>,
type_span: Option<Span>
}
// Records a possibly-private value definition.
#[deriving(Clone)]
2013-10-02 07:33:01 -05:00
struct ValueNsDef {
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
is_public: bool, // see note in ImportResolution about how to use this
def: Def,
value_span: Option<Span>,
}
// Records the definitions (at most one for each namespace) that a name is
// bound to.
2013-10-02 07:33:01 -05:00
struct NameBindings {
type_def: RefCell<Option<TypeNsDef>>, //< Meaning in type namespace.
value_def: RefCell<Option<ValueNsDef>>, //< Meaning in value namespace.
}
/// Ways in which a trait can be referenced
enum TraitReferenceType {
TraitImplementation, // impl SomeTrait for T { ... }
TraitDerivation, // trait T : SomeTrait { ... }
TraitBoundingTypeParameter, // fn f<T:SomeTrait>() { ... }
}
impl NameBindings {
/// Creates a new module in this set of name bindings.
2013-12-21 16:20:57 -06:00
fn define_module(&self,
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
parent_link: ParentLink,
def_id: Option<DefId>,
kind: ModuleKind,
external: bool,
is_public: bool,
sp: Span) {
// Merges the module with the existing type def or creates a new one.
2013-12-19 21:02:22 -06:00
let module_ = @Module::new(parent_link, def_id, kind, external,
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
is_public);
match self.type_def.get() {
None => {
self.type_def.set(Some(TypeNsDef {
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
is_public: is_public,
module_def: Some(module_),
type_def: None,
type_span: Some(sp)
}));
}
2013-05-29 18:59:33 -05:00
Some(type_def) => {
self.type_def.set(Some(TypeNsDef {
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
is_public: is_public,
module_def: Some(module_),
type_span: Some(sp),
2013-05-29 18:59:33 -05:00
type_def: type_def.type_def
}));
}
}
}
/// Sets the kind of the module, creating a new one if necessary.
2013-12-21 16:20:57 -06:00
fn set_module_kind(&self,
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
parent_link: ParentLink,
def_id: Option<DefId>,
kind: ModuleKind,
external: bool,
is_public: bool,
_sp: Span) {
match self.type_def.get() {
None => {
2013-12-19 21:02:22 -06:00
let module = @Module::new(parent_link, def_id, kind,
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
external, is_public);
self.type_def.set(Some(TypeNsDef {
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
is_public: is_public,
module_def: Some(module),
type_def: None,
type_span: None,
}))
}
Some(type_def) => {
match type_def.module_def {
None => {
2013-12-19 21:02:22 -06:00
let module = @Module::new(parent_link,
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
def_id,
kind,
external,
is_public);
self.type_def.set(Some(TypeNsDef {
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
is_public: is_public,
module_def: Some(module),
type_def: type_def.type_def,
type_span: None,
}))
}
Some(module_def) => module_def.kind.set(kind),
}
}
}
}
/// Records a type definition.
2013-12-21 16:20:57 -06:00
fn define_type(&self, def: Def, sp: Span, is_public: bool) {
// Merges the type with the existing type def or creates a new one.
match self.type_def.get() {
None => {
self.type_def.set(Some(TypeNsDef {
module_def: None,
type_def: Some(def),
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
type_span: Some(sp),
is_public: is_public,
}));
}
2013-05-29 18:59:33 -05:00
Some(type_def) => {
self.type_def.set(Some(TypeNsDef {
type_def: Some(def),
type_span: Some(sp),
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
module_def: type_def.module_def,
is_public: is_public,
}));
}
}
}
/// Records a value definition.
2013-12-21 16:20:57 -06:00
fn define_value(&self, def: Def, sp: Span, is_public: bool) {
self.value_def.set(Some(ValueNsDef {
def: def,
value_span: Some(sp),
is_public: is_public,
}));
}
/// Returns the module node if applicable.
2013-12-19 21:02:22 -06:00
fn get_module_if_available(&self) -> Option<@Module> {
let type_def = self.type_def.borrow();
match *type_def.get() {
Some(ref type_def) => (*type_def).module_def,
None => None
}
}
/**
* Returns the module node. Fails if this node does not have a module
* definition.
*/
2013-12-21 16:20:57 -06:00
fn get_module(&self) -> @Module {
match self.get_module_if_available() {
None => {
fail!("get_module called on a node with no module \
definition!")
}
Some(module_def) => module_def
}
}
2013-10-02 07:33:01 -05:00
fn defined_in_namespace(&self, namespace: Namespace) -> bool {
2012-08-06 14:34:08 -05:00
match namespace {
TypeNS => return self.type_def.get().is_some(),
ValueNS => return self.value_def.get().is_some()
}
}
2013-10-02 07:33:01 -05:00
fn defined_in_public_namespace(&self, namespace: Namespace) -> bool {
match namespace {
TypeNS => match self.type_def.get() {
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
Some(def) => def.is_public, None => false
},
ValueNS => match self.value_def.get() {
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
Some(def) => def.is_public, None => false
}
}
}
2013-10-02 07:33:01 -05:00
fn def_for_namespace(&self, namespace: Namespace) -> Option<Def> {
2012-08-06 14:34:08 -05:00
match namespace {
TypeNS => {
match self.type_def.get() {
None => None,
Some(type_def) => {
match type_def.type_def {
Some(type_def) => Some(type_def),
None => {
match type_def.module_def {
Some(module) => {
match module.def_id.get() {
Some(did) => Some(DefMod(did)),
None => None,
}
}
None => None,
}
}
}
}
}
}
ValueNS => {
match self.value_def.get() {
None => None,
Some(value_def) => Some(value_def.def)
}
}
}
}
2013-10-02 07:33:01 -05:00
fn span_for_namespace(&self, namespace: Namespace) -> Option<Span> {
if self.defined_in_namespace(namespace) {
match namespace {
TypeNS => {
match self.type_def.get() {
None => None,
Some(type_def) => type_def.type_span
}
}
ValueNS => {
match self.value_def.get() {
None => None,
Some(value_def) => value_def.value_span
}
}
}
} else {
None
}
}
}
2013-10-02 07:33:01 -05:00
fn NameBindings() -> NameBindings {
2012-09-05 17:58:43 -05:00
NameBindings {
type_def: RefCell::new(None),
value_def: RefCell::new(None),
2012-09-05 17:58:43 -05:00
}
}
/// Interns the names of the primitive types.
2013-10-02 07:33:01 -05:00
struct PrimitiveTypeTable {
primitive_types: HashMap<Name, PrimTy>,
}
impl PrimitiveTypeTable {
fn intern(&mut self, string: &str, primitive_type: PrimTy) {
self.primitive_types.insert(token::intern(string), primitive_type);
}
}
2013-10-02 07:33:01 -05:00
fn PrimitiveTypeTable() -> PrimitiveTypeTable {
2013-03-22 21:26:41 -05:00
let mut table = PrimitiveTypeTable {
primitive_types: HashMap::new()
2012-09-05 17:58:43 -05:00
};
table.intern("bool", TyBool);
table.intern("char", TyChar);
table.intern("f32", TyFloat(TyF32));
table.intern("f64", TyFloat(TyF64));
table.intern("int", TyInt(TyI));
table.intern("i8", TyInt(TyI8));
table.intern("i16", TyInt(TyI16));
table.intern("i32", TyInt(TyI32));
table.intern("i64", TyInt(TyI64));
table.intern("str", TyStr);
table.intern("uint", TyUint(TyU));
table.intern("u8", TyUint(TyU8));
table.intern("u16", TyUint(TyU16));
table.intern("u32", TyUint(TyU32));
table.intern("u64", TyUint(TyU64));
2012-09-05 17:58:43 -05:00
return table;
}
2013-10-02 07:33:01 -05:00
fn namespace_error_to_str(ns: NamespaceError) -> &'static str {
match ns {
NoError => "",
ModuleError => "module",
TypeError => "type",
ValueError => "value",
}
}
2013-10-02 07:33:01 -05:00
fn Resolver(session: Session,
lang_items: @LanguageItems,
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
crate_span: Span) -> Resolver {
2013-12-21 16:20:57 -06:00
let graph_root = @NameBindings();
2012-09-05 17:58:43 -05:00
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
graph_root.define_module(NoParentLink,
Some(DefId { crate: 0, node: 0 }),
NormalModuleKind,
false,
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
true,
2013-09-27 21:46:09 -05:00
crate_span);
2012-09-05 17:58:43 -05:00
let current_module = graph_root.get_module();
2012-09-05 17:58:43 -05:00
let this = Resolver {
2013-02-21 13:08:50 -06:00
session: @session,
lang_items: lang_items,
2012-09-05 17:58:43 -05:00
// The outermost module has def ID 0; this is not reflected in the
// AST.
graph_root: graph_root,
2013-12-21 19:04:42 -06:00
method_map: @RefCell::new(HashMap::new()),
structs: HashSet::new(),
2012-09-05 17:58:43 -05:00
unresolved_imports: 0,
2012-09-05 17:58:43 -05:00
current_module: current_module,
value_ribs: @RefCell::new(~[]),
type_ribs: @RefCell::new(~[]),
label_ribs: @RefCell::new(~[]),
2012-09-05 17:58:43 -05:00
current_trait_refs: None,
self_ident: special_idents::self_,
type_self_ident: special_idents::type_self,
2013-06-04 17:14:56 -05:00
primitive_type_table: @PrimitiveTypeTable(),
2012-09-05 17:58:43 -05:00
namespaces: ~[ TypeNS, ValueNS ],
2012-09-05 17:58:43 -05:00
def_map: @RefCell::new(HashMap::new()),
2013-12-20 23:14:25 -06:00
export_map2: @RefCell::new(HashMap::new()),
trait_map: HashMap::new(),
used_imports: HashSet::new(),
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
external_exports: HashSet::new(),
last_private: HashMap::new(),
2012-09-05 17:58:43 -05:00
emit_errors: true,
2012-09-05 17:58:43 -05:00
intr: session.intr()
};
this
2012-09-05 17:58:43 -05:00
}
/// The main resolver class.
2013-10-02 07:33:01 -05:00
struct Resolver {
2013-02-21 13:08:50 -06:00
session: @Session,
lang_items: @LanguageItems,
intr: @IdentInterner,
2013-12-21 16:20:57 -06:00
graph_root: @NameBindings,
2013-12-21 19:04:42 -06:00
method_map: @RefCell<HashMap<Name, HashSet<DefId>>>,
structs: HashSet<DefId>,
// The number of imports that are currently unresolved.
2013-02-21 13:08:50 -06:00
unresolved_imports: uint,
// The module that represents the current item scope.
2013-12-19 21:02:22 -06:00
current_module: @Module,
// The current set of local scopes, for values.
// FIXME #4948: Reuse ribs to avoid allocation.
value_ribs: @RefCell<~[@Rib]>,
// The current set of local scopes, for types.
type_ribs: @RefCell<~[@Rib]>,
// The current set of local scopes, for labels.
label_ribs: @RefCell<~[@Rib]>,
// The trait that the current context can refer to.
current_trait_refs: Option<~[DefId]>,
2012-09-19 20:52:49 -05:00
// The ident for the keyword "self".
2013-09-01 19:50:59 -05:00
self_ident: Ident,
// The ident for the non-keyword "Self".
2013-09-01 19:50:59 -05:00
type_self_ident: Ident,
2012-09-19 20:52:49 -05:00
// The idents for the primitive types.
2012-09-06 21:40:15 -05:00
primitive_type_table: @PrimitiveTypeTable,
// The four namespaces.
2012-09-06 21:40:15 -05:00
namespaces: ~[Namespace],
2013-03-22 21:26:41 -05:00
def_map: DefMap,
export_map2: ExportMap2,
2012-09-06 21:40:15 -05:00
trait_map: TraitMap,
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
external_exports: ExternalExports,
last_private: LastPrivateMap,
// Whether or not to print error messages. Can be set to true
// when getting additional info for error message suggestions,
// so as to avoid printing duplicate errors
emit_errors: bool,
used_imports: HashSet<NodeId>,
}
struct BuildReducedGraphVisitor<'a> {
resolver: &'a mut Resolver,
}
impl<'a> Visitor<ReducedGraphParent> for BuildReducedGraphVisitor<'a> {
fn visit_item(&mut self, item: &Item, context: ReducedGraphParent) {
let p = self.resolver.build_reduced_graph_for_item(item, context);
visit::walk_item(self, item, p);
}
fn visit_foreign_item(&mut self, foreign_item: &ForeignItem,
2014-01-06 06:00:46 -06:00
context: ReducedGraphParent) {
self.resolver.build_reduced_graph_for_foreign_item(foreign_item,
context,
|r, c| {
let mut v = BuildReducedGraphVisitor{ resolver: r };
visit::walk_foreign_item(&mut v, foreign_item, c);
})
}
fn visit_view_item(&mut self, view_item: &ViewItem, context: ReducedGraphParent) {
self.resolver.build_reduced_graph_for_view_item(view_item, context);
}
2014-01-06 06:00:46 -06:00
fn visit_block(&mut self, block: &Block, context: ReducedGraphParent) {
let np = self.resolver.build_reduced_graph_for_block(block, context);
visit::walk_block(self, block, np);
}
}
struct UnusedImportCheckVisitor<'a> { resolver: &'a Resolver }
impl<'a> Visitor<()> for UnusedImportCheckVisitor<'a> {
fn visit_view_item(&mut self, vi: &ViewItem, _: ()) {
self.resolver.check_for_item_unused_imports(vi);
visit::walk_view_item(self, vi, ());
}
}
impl Resolver {
/// The main name resolution procedure.
2013-10-02 07:33:01 -05:00
fn resolve(&mut self, crate: &ast::Crate) {
2013-09-27 21:46:09 -05:00
self.build_reduced_graph(crate);
self.session.abort_if_errors();
self.resolve_imports();
self.session.abort_if_errors();
self.record_exports();
self.session.abort_if_errors();
2013-09-27 21:46:09 -05:00
self.resolve_crate(crate);
self.session.abort_if_errors();
2013-09-27 21:46:09 -05:00
self.check_for_unused_imports(crate);
}
//
// Reduced graph building
//
// Here we build the "reduced graph": the graph of the module tree without
// any imports resolved.
//
/// Constructs the reduced graph for the entire crate.
2013-10-02 07:33:01 -05:00
fn build_reduced_graph(&mut self, crate: &ast::Crate) {
let initial_parent =
ModuleReducedGraphParent(self.graph_root.get_module());
let mut visitor = BuildReducedGraphVisitor { resolver: self, };
2013-09-27 21:46:09 -05:00
visit::walk_crate(&mut visitor, crate, initial_parent);
}
/// Returns the current module tracked by the reduced graph parent.
2013-10-02 07:33:01 -05:00
fn get_module_from_parent(&mut self,
reduced_graph_parent: ReducedGraphParent)
2013-12-19 21:02:22 -06:00
-> @Module {
2012-08-06 14:34:08 -05:00
match reduced_graph_parent {
2012-08-03 21:59:04 -05:00
ModuleReducedGraphParent(module_) => {
2012-08-01 19:30:05 -05:00
return module_;
}
}
}
/**
* Adds a new child item to the module definition of the parent node and
* returns its corresponding name bindings as well as the current parent.
* Or, if we're inside a block, creates (or reuses) an anonymous module
* corresponding to the innermost block ID and returns the name bindings
* as well as the newly-created parent.
*
* If this node does not have a module definition and we are not inside
* a block, fails.
*/
2013-10-02 07:33:01 -05:00
fn add_child(&mut self,
2013-09-01 19:50:59 -05:00
name: Ident,
reduced_graph_parent: ReducedGraphParent,
duplicate_checking_mode: DuplicateCheckingMode,
// For printing errors
sp: Span)
2013-12-21 16:20:57 -06:00
-> (@NameBindings, ReducedGraphParent) {
// If this is the immediate descendant of a module, then we add the
// child name directly. Otherwise, we create or reuse an anonymous
// module and add the child to that.
2013-04-12 00:15:30 -05:00
let module_;
2012-08-06 14:34:08 -05:00
match reduced_graph_parent {
2012-08-03 21:59:04 -05:00
ModuleReducedGraphParent(parent_module) => {
module_ = parent_module;
}
}
// Add or reuse the child.
let new_parent = ModuleReducedGraphParent(module_);
2013-12-21 17:32:44 -06:00
let child_opt = {
let children = module_.children.borrow();
children.get().find_copy(&name.name)
};
match child_opt {
2012-08-20 14:23:37 -05:00
None => {
2013-12-21 16:20:57 -06:00
let child = @NameBindings();
2013-12-21 17:32:44 -06:00
let mut children = module_.children.borrow_mut();
children.get().insert(name.name, child);
return (child, new_parent);
}
2013-12-21 17:32:44 -06:00
Some(child) => {
// Enforce the duplicate checking mode:
//
// * If we're requesting duplicate module checking, check that
// there isn't a module in the module with the same name.
//
// * If we're requesting duplicate type checking, check that
// there isn't a type in the module with the same name.
//
// * If we're requesting duplicate value checking, check that
// there isn't a value in the module with the same name.
//
// * If we're requesting duplicate type checking and duplicate
// value checking, check that there isn't a duplicate type
// and a duplicate value with the same name.
//
// * If no duplicate checking was requested at all, do
// nothing.
let mut duplicate_type = NoError;
let ns = match duplicate_checking_mode {
ForbidDuplicateModules => {
2014-01-19 02:21:14 -06:00
if child.get_module_if_available().is_some() {
duplicate_type = ModuleError;
}
Some(TypeNS)
}
ForbidDuplicateTypes => {
match child.def_for_namespace(TypeNS) {
Some(DefMod(_)) | None => {}
Some(_) => duplicate_type = TypeError
}
Some(TypeNS)
}
ForbidDuplicateValues => {
if child.defined_in_namespace(ValueNS) {
duplicate_type = ValueError;
}
Some(ValueNS)
}
ForbidDuplicateTypesAndValues => {
let mut n = None;
match child.def_for_namespace(TypeNS) {
Some(DefMod(_)) | None => {}
Some(_) => {
n = Some(TypeNS);
duplicate_type = TypeError;
}
};
if child.defined_in_namespace(ValueNS) {
duplicate_type = ValueError;
n = Some(ValueNS);
}
n
}
OverwriteDuplicates => None
};
2014-01-19 02:21:14 -06:00
if duplicate_type != NoError {
// Return an error here by looking up the namespace that
// had the duplicate.
let ns = ns.unwrap();
self.resolve_error(sp,
2013-09-28 00:38:08 -05:00
format!("duplicate definition of {} `{}`",
namespace_error_to_str(duplicate_type),
self.session.str_of(name)));
{
let r = child.span_for_namespace(ns);
for sp in r.iter() {
self.session.span_note(*sp,
2013-09-28 00:38:08 -05:00
format!("first definition of {} `{}` here",
namespace_error_to_str(duplicate_type),
self.session.str_of(name)));
}
}
}
2013-03-15 14:24:24 -05:00
return (child, new_parent);
}
}
}
2013-10-02 07:33:01 -05:00
fn block_needs_anonymous_module(&mut self, block: &Block) -> bool {
// If the block has view items, we need an anonymous module.
if block.view_items.len() > 0 {
2012-08-01 19:30:05 -05:00
return true;
}
// Check each statement.
for statement in block.stmts.iter() {
2012-08-06 14:34:08 -05:00
match statement.node {
StmtDecl(declaration, _) => {
2012-08-06 14:34:08 -05:00
match declaration.node {
DeclItem(_) => {
2012-08-01 19:30:05 -05:00
return true;
}
2012-08-03 21:59:04 -05:00
_ => {
// Keep searching.
}
}
}
2012-08-03 21:59:04 -05:00
_ => {
// Keep searching.
}
}
}
// If we found neither view items nor items, we don't need to create
// an anonymous module.
2012-08-01 19:30:05 -05:00
return false;
}
2013-10-02 07:33:01 -05:00
fn get_parent_link(&mut self, parent: ReducedGraphParent, name: Ident)
-> ParentLink {
2012-08-06 14:34:08 -05:00
match parent {
2012-08-03 21:59:04 -05:00
ModuleReducedGraphParent(module_) => {
2012-08-01 19:30:05 -05:00
return ModuleParentLink(module_, name);
}
}
}
/// Constructs the reduced graph for one item.
2013-10-02 07:33:01 -05:00
fn build_reduced_graph_for_item(&mut self,
item: &Item,
parent: ReducedGraphParent)
-> ReducedGraphParent
{
2012-09-19 20:52:49 -05:00
let ident = item.ident;
let sp = item.span;
let is_public = item.vis == ast::Public;
match item.node {
ItemMod(..) => {
let (name_bindings, new_parent) =
self.add_child(ident, parent, ForbidDuplicateModules, sp);
2012-09-19 20:52:49 -05:00
let parent_link = self.get_parent_link(new_parent, ident);
let def_id = DefId { crate: 0, node: item.id };
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
name_bindings.define_module(parent_link,
Some(def_id),
NormalModuleKind,
false,
item.vis == ast::Public,
sp);
ModuleReducedGraphParent(name_bindings.get_module())
}
ItemForeignMod(..) => parent,
// These items live in the value namespace.
ItemStatic(_, m, _) => {
let (name_bindings, _) =
self.add_child(ident, parent, ForbidDuplicateValues, sp);
let mutbl = m == ast::MutMutable;
name_bindings.define_value
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
(DefStatic(local_def(item.id), mutbl), sp, is_public);
parent
}
ItemFn(_, purity, _, _, _) => {
let (name_bindings, new_parent) =
self.add_child(ident, parent, ForbidDuplicateValues, sp);
let def = DefFn(local_def(item.id), purity);
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
name_bindings.define_value(def, sp, is_public);
new_parent
}
// These items live in the type namespace.
ItemTy(..) => {
let (name_bindings, _) =
self.add_child(ident, parent, ForbidDuplicateTypes, sp);
name_bindings.define_type
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
(DefTy(local_def(item.id)), sp, is_public);
parent
}
ItemEnum(ref enum_definition, _) => {
let (name_bindings, new_parent) =
self.add_child(ident, parent, ForbidDuplicateTypes, sp);
name_bindings.define_type
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
(DefTy(local_def(item.id)), sp, is_public);
for &variant in (*enum_definition).variants.iter() {
self.build_reduced_graph_for_variant(
variant,
local_def(item.id),
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
new_parent,
is_public);
}
parent
}
// These items live in both the type and value namespaces.
ItemStruct(struct_def, _) => {
// Adding to both Type and Value namespaces or just Type?
let (forbid, ctor_id) = match struct_def.ctor_id {
Some(ctor_id) => (ForbidDuplicateTypesAndValues, Some(ctor_id)),
None => (ForbidDuplicateTypes, None)
};
let (name_bindings, new_parent) = self.add_child(ident, parent, forbid, sp);
// Define a name in the type namespace.
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
name_bindings.define_type(DefTy(local_def(item.id)), sp, is_public);
// If this is a newtype or unit-like struct, define a name
// in the value namespace as well
ctor_id.while_some(|cid| {
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
name_bindings.define_value(DefStruct(local_def(cid)), sp,
is_public);
None
});
// Record the def ID of this struct.
2013-03-22 21:26:41 -05:00
self.structs.insert(local_def(item.id));
new_parent
}
ItemImpl(_, None, ty, ref methods) => {
// If this implements an anonymous trait, then add all the
// methods within to a new module, if the type was defined
// within this module.
//
// FIXME (#3785): This is quite unsatisfactory. Perhaps we
// should modify anonymous traits to only be implementable in
// the same module that declared the type.
// Create the module and add all methods.
match ty.node {
TyPath(ref path, _, _) if path.segments.len() == 1 => {
let name = path_to_ident(path);
2013-12-21 17:32:44 -06:00
let existing_parent_opt = {
let children = parent.module().children.borrow();
2013-12-21 17:32:44 -06:00
children.get().find_copy(&name.name)
};
let new_parent = match existing_parent_opt {
// It already exists
2013-12-21 17:32:44 -06:00
Some(child) if child.get_module_if_available()
.is_some() &&
child.get_module().kind.get() ==
ImplModuleKind => {
ModuleReducedGraphParent(child.get_module())
}
// Create the module
_ => {
let (name_bindings, new_parent) =
self.add_child(name,
parent,
ForbidDuplicateModules,
sp);
let parent_link =
self.get_parent_link(new_parent, ident);
let def_id = local_def(item.id);
let ns = TypeNS;
let is_public =
!name_bindings.defined_in_namespace(ns) ||
name_bindings.defined_in_public_namespace(ns);
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
name_bindings.define_module(parent_link,
Some(def_id),
ImplModuleKind,
false,
is_public,
sp);
ModuleReducedGraphParent(
name_bindings.get_module())
}
};
// For each method...
for method in methods.iter() {
// Add the method to the module.
let ident = method.ident;
let (method_name_bindings, _) =
self.add_child(ident,
new_parent,
ForbidDuplicateValues,
method.span);
let def = match method.explicit_self.node {
SelfStatic => {
// Static methods become
// `def_static_method`s.
DefStaticMethod(local_def(method.id),
FromImpl(local_def(
item.id)),
method.purity)
}
_ => {
// Non-static methods become
// `def_method`s.
DefMethod(local_def(method.id), None)
}
};
let is_public = method.vis == ast::Public;
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
method_name_bindings.define_value(def,
method.span,
is_public);
}
}
_ => {}
}
parent
}
ItemImpl(_, Some(_), _, _) => parent,
ItemTrait(_, _, ref methods) => {
let (name_bindings, new_parent) =
self.add_child(ident, parent, ForbidDuplicateTypes, sp);
// Add all the methods within to a new module.
let parent_link = self.get_parent_link(parent, ident);
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
name_bindings.define_module(parent_link,
Some(local_def(item.id)),
TraitModuleKind,
false,
item.vis == ast::Public,
sp);
let module_parent = ModuleReducedGraphParent(name_bindings.
get_module());
// Add the names of all the methods to the trait info.
let mut method_names = HashMap::new();
for method in methods.iter() {
let ty_m = trait_method_to_ty_method(method);
2012-09-19 20:52:49 -05:00
let ident = ty_m.ident;
// Add it as a name in the trait module.
let def = match ty_m.explicit_self.node {
SelfStatic => {
// Static methods become `def_static_method`s.
DefStaticMethod(local_def(ty_m.id),
FromTrait(local_def(item.id)),
ty_m.purity)
}
_ => {
// Non-static methods become `def_method`s.
DefMethod(local_def(ty_m.id),
Some(local_def(item.id)))
}
};
let (method_name_bindings, _) =
self.add_child(ident,
module_parent,
ForbidDuplicateValues,
ty_m.span);
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
method_name_bindings.define_value(def, ty_m.span, true);
// Add it to the trait info if not static.
match ty_m.explicit_self.node {
SelfStatic => {}
_ => {
method_names.insert(ident.name, ());
}
}
}
let def_id = local_def(item.id);
for (name, _) in method_names.iter() {
2013-12-21 19:04:42 -06:00
let mut method_map = self.method_map.borrow_mut();
if !method_map.get().contains_key(name) {
method_map.get().insert(*name, HashSet::new());
}
2013-12-21 19:04:42 -06:00
match method_map.get().find_mut(name) {
Some(s) => { s.insert(def_id); },
_ => fail!("can't happen"),
}
}
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
name_bindings.define_type(DefTrait(def_id), sp, is_public);
new_parent
}
2013-12-25 12:10:33 -06:00
ItemMac(..) => parent
}
}
// Constructs the reduced graph for one variant. Variants exist in the
// type and/or value namespaces.
2013-10-02 07:33:01 -05:00
fn build_reduced_graph_for_variant(&mut self,
variant: &Variant,
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
item_id: DefId,
parent: ReducedGraphParent,
parent_public: bool) {
2012-09-19 20:52:49 -05:00
let ident = variant.node.name;
// FIXME: this is unfortunate to have to do this privacy calculation
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
// here. This should be living in middle::privacy, but it's
// necessary to keep around in some form becaues of glob imports...
let is_public = parent_public && variant.node.vis != ast::Private;
match variant.node.kind {
TupleVariantKind(_) => {
let (child, _) = self.add_child(ident, parent, ForbidDuplicateValues,
variant.span);
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
child.define_value(DefVariant(item_id,
local_def(variant.node.id), false),
variant.span, is_public);
}
StructVariantKind(_) => {
let (child, _) = self.add_child(ident, parent, ForbidDuplicateTypesAndValues,
variant.span);
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
child.define_type(DefVariant(item_id,
local_def(variant.node.id), true),
variant.span, is_public);
2013-03-22 21:26:41 -05:00
self.structs.insert(local_def(variant.node.id));
}
}
}
/// Constructs the reduced graph for one 'view item'. View items consist
/// of imports and use directives.
fn build_reduced_graph_for_view_item(&mut self, view_item: &ViewItem,
parent: ReducedGraphParent) {
match view_item.node {
ViewItemUse(ref view_paths) => {
for view_path in view_paths.iter() {
// Extract and intern the module part of the path. For
// globs and lists, the path is found directly in the AST;
// for simple paths we have to munge the path a little.
2013-03-07 17:37:14 -06:00
let mut module_path = ~[];
2012-08-06 14:34:08 -05:00
match view_path.node {
ViewPathSimple(_, ref full_path, _) => {
let path_len = full_path.segments.len();
2013-03-28 20:39:09 -05:00
assert!(path_len != 0);
for (i, segment) in full_path.segments
.iter()
.enumerate() {
if i != path_len - 1 {
module_path.push(segment.identifier)
}
}
}
ViewPathGlob(ref module_ident_path, _) |
ViewPathList(ref module_ident_path, _, _) => {
for segment in module_ident_path.segments.iter() {
module_path.push(segment.identifier)
}
}
}
// Build up the import directives.
let module_ = self.get_module_from_parent(parent);
let is_public = view_item.vis == ast::Public;
2012-08-06 14:34:08 -05:00
match view_path.node {
ViewPathSimple(binding, ref full_path, id) => {
let source_ident =
full_path.segments.last().unwrap().identifier;
2012-07-18 18:18:02 -05:00
let subclass = @SingleImport(binding,
source_ident);
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
self.build_import_directive(module_,
module_path,
subclass,
view_path.span,
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
id,
is_public);
}
ViewPathList(_, ref source_idents, _) => {
for source_ident in source_idents.iter() {
let name = source_ident.node.name;
let subclass = @SingleImport(name, name);
2013-07-02 14:47:32 -05:00
self.build_import_directive(
module_,
module_path.clone(),
subclass,
source_ident.span,
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
source_ident.node.id,
is_public);
}
}
ViewPathGlob(_, id) => {
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
self.build_import_directive(module_,
module_path,
@GlobImport,
view_path.span,
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
id,
is_public);
}
}
}
}
ViewItemExternMod(name, _, node_id) => {
// n.b. we don't need to look at the path option here, because cstore already did
2013-12-25 14:08:04 -06:00
match self.session.cstore.find_extern_mod_stmt_cnum(node_id) {
2012-08-20 14:23:37 -05:00
Some(crate_id) => {
let def_id = DefId { crate: crate_id, node: 0 };
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
self.external_exports.insert(def_id);
let parent_link = ModuleParentLink
(self.get_module_from_parent(parent), name);
2013-12-19 21:02:22 -06:00
let external_module = @Module::new(parent_link,
Some(def_id),
NormalModuleKind,
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
false,
true);
{
let mut external_module_children =
parent.module().external_module_children.borrow_mut();
external_module_children.get().insert(
name.name,
external_module);
}
self.build_reduced_graph_for_external_crate(
external_module);
}
None => {} // Ignore.
}
}
}
}
/// Constructs the reduced graph for one foreign item.
2013-10-02 07:33:01 -05:00
fn build_reduced_graph_for_foreign_item(&mut self,
foreign_item: &ForeignItem,
parent: ReducedGraphParent,
f: |&mut Resolver,
ReducedGraphParent|) {
2012-07-18 18:18:02 -05:00
let name = foreign_item.ident;
let is_public = foreign_item.vis == ast::Public;
let (name_bindings, new_parent) =
self.add_child(name, parent, ForbidDuplicateValues,
foreign_item.span);
match foreign_item.node {
ForeignItemFn(_, ref generics) => {
let def = DefFn(local_def(foreign_item.id), UnsafeFn);
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
name_bindings.define_value(def, foreign_item.span, is_public);
self.with_type_parameter_rib(
HasTypeParameters(generics,
foreign_item.id,
0,
NormalRibKind),
|this| f(this, new_parent));
}
ForeignItemStatic(_, m) => {
let def = DefStatic(local_def(foreign_item.id), m);
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
name_bindings.define_value(def, foreign_item.span, is_public);
f(self, new_parent)
}
}
}
2013-10-02 07:33:01 -05:00
fn build_reduced_graph_for_block(&mut self,
block: &Block,
parent: ReducedGraphParent)
-> ReducedGraphParent
{
if self.block_needs_anonymous_module(block) {
let block_id = block.id;
debug!("(building reduced graph for block) creating a new \
2013-09-28 00:38:08 -05:00
anonymous module for block {}",
2012-08-22 19:24:52 -05:00
block_id);
let parent_module = self.get_module_from_parent(parent);
2013-12-19 21:02:22 -06:00
let new_module = @Module::new(
2013-02-21 13:08:50 -06:00
BlockParentLink(parent_module, block_id),
None,
AnonymousModuleKind,
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
false,
false);
{
let mut anonymous_children = parent_module.anonymous_children
.borrow_mut();
anonymous_children.get().insert(block_id, new_module);
ModuleReducedGraphParent(new_module)
}
} else {
parent
}
}
fn handle_external_def(&mut self,
def: Def,
vis: Visibility,
2013-12-21 16:20:57 -06:00
child_name_bindings: @NameBindings,
final_ident: &str,
2013-09-01 19:50:59 -05:00
ident: Ident,
new_parent: ReducedGraphParent) {
debug!("(building reduced graph for \
2013-09-28 00:38:08 -05:00
external crate) building external def, priv {:?}",
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
vis);
let is_public = vis == ast::Public;
2013-10-07 15:01:47 -05:00
let is_exported = is_public && match new_parent {
ModuleReducedGraphParent(module) => {
match module.def_id.get() {
2013-10-07 15:01:47 -05:00
None => true,
Some(did) => self.external_exports.contains(&did)
}
}
};
if is_exported {
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
self.external_exports.insert(def_id_of_def(def));
}
match def {
DefMod(def_id) | DefForeignMod(def_id) | DefStruct(def_id) |
DefTy(def_id) => {
match child_name_bindings.type_def.get() {
2013-11-28 14:22:53 -06:00
Some(TypeNsDef { module_def: Some(module_def), .. }) => {
debug!("(building reduced graph for external crate) \
already created module");
module_def.def_id.set(Some(def_id));
}
Some(_) | None => {
debug!("(building reduced graph for \
external crate) building module \
2013-09-28 00:38:08 -05:00
{}", final_ident);
2012-09-19 20:52:49 -05:00
let parent_link = self.get_parent_link(new_parent, ident);
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
child_name_bindings.define_module(parent_link,
Some(def_id),
NormalModuleKind,
true,
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
is_public,
DUMMY_SP);
}
}
}
_ => {}
}
match def {
DefMod(_) | DefForeignMod(_) => {}
DefVariant(_, variant_id, is_struct) => {
debug!("(building reduced graph for external crate) building \
2013-09-28 00:38:08 -05:00
variant {}",
final_ident);
// We assume the parent is visible, or else we wouldn't have seen
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
// it. Also variants are public-by-default if the parent was also
// public.
let is_public = vis != ast::Private;
if is_struct {
child_name_bindings.define_type(def, DUMMY_SP, is_public);
self.structs.insert(variant_id);
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
} else {
child_name_bindings.define_value(def, DUMMY_SP, is_public);
}
}
2013-11-28 14:22:53 -06:00
DefFn(..) | DefStaticMethod(..) | DefStatic(..) => {
debug!("(building reduced graph for external \
2013-09-28 00:38:08 -05:00
crate) building value (fn/static) {}", final_ident);
child_name_bindings.define_value(def, DUMMY_SP, is_public);
}
DefTrait(def_id) => {
debug!("(building reduced graph for external \
2013-09-28 00:38:08 -05:00
crate) building type {}", final_ident);
// If this is a trait, add all the method names
// to the trait info.
let method_def_ids =
2013-12-25 14:08:04 -06:00
csearch::get_trait_method_def_ids(self.session.cstore, def_id);
let mut interned_method_names = HashSet::new();
for &method_def_id in method_def_ids.iter() {
let (method_name, explicit_self) =
2013-12-25 14:08:04 -06:00
csearch::get_method_name_and_explicit_self(self.session.cstore,
method_def_id);
debug!("(building reduced graph for \
external crate) ... adding \
2013-09-28 00:38:08 -05:00
trait method '{}'",
self.session.str_of(method_name));
// Add it to the trait info if not static.
if explicit_self != SelfStatic {
interned_method_names.insert(method_name.name);
}
2013-10-07 15:01:47 -05:00
if is_exported {
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
self.external_exports.insert(method_def_id);
}
}
for name in interned_method_names.iter() {
2013-12-21 19:04:42 -06:00
let mut method_map = self.method_map.borrow_mut();
if !method_map.get().contains_key(name) {
method_map.get().insert(*name, HashSet::new());
}
2013-12-21 19:04:42 -06:00
match method_map.get().find_mut(name) {
Some(s) => { s.insert(def_id); },
_ => fail!("can't happen"),
}
}
child_name_bindings.define_type(def, DUMMY_SP, is_public);
// Define a module if necessary.
let parent_link = self.get_parent_link(new_parent, ident);
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
child_name_bindings.set_module_kind(parent_link,
Some(def_id),
TraitModuleKind,
true,
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
is_public,
DUMMY_SP)
}
DefTy(_) => {
debug!("(building reduced graph for external \
2013-09-28 00:38:08 -05:00
crate) building type {}", final_ident);
child_name_bindings.define_type(def, DUMMY_SP, is_public);
}
DefStruct(def_id) => {
debug!("(building reduced graph for external \
2013-09-28 00:38:08 -05:00
crate) building type and value for {}",
final_ident);
child_name_bindings.define_type(def, DUMMY_SP, is_public);
2013-12-25 14:08:04 -06:00
if csearch::get_struct_fields(self.session.cstore, def_id).len() == 0 {
child_name_bindings.define_value(def, DUMMY_SP, is_public);
}
2013-03-22 21:26:41 -05:00
self.structs.insert(def_id);
}
2013-11-28 14:22:53 -06:00
DefMethod(..) => {
debug!("(building reduced graph for external crate) \
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
ignoring {:?}", def);
// Ignored; handled elsewhere.
}
DefArg(..) | DefLocal(..) | DefPrimTy(..) |
DefTyParam(..) | DefBinding(..) |
2013-11-28 14:22:53 -06:00
DefUse(..) | DefUpvar(..) | DefRegion(..) |
DefTyParamBinder(..) | DefLabel(..) | DefSelfTy(..) => {
fail!("didn't expect `{:?}`", def);
}
}
}
/// Builds the reduced graph for a single item in an external crate.
fn build_reduced_graph_for_external_crate_def(&mut self,
2013-12-19 21:02:22 -06:00
root: @Module,
def_like: DefLike,
ident: Ident,
visibility: Visibility) {
match def_like {
DlDef(def) => {
// Add the new child item, if necessary.
match def {
DefForeignMod(def_id) => {
// Foreign modules have no names. Recur and populate
// eagerly.
csearch::each_child_of_item(self.session.cstore,
def_id,
|def_like,
child_ident,
vis| {
self.build_reduced_graph_for_external_crate_def(
root,
def_like,
child_ident,
vis)
});
}
_ => {
let (child_name_bindings, new_parent) =
self.add_child(ident,
ModuleReducedGraphParent(root),
OverwriteDuplicates,
DUMMY_SP);
self.handle_external_def(def,
visibility,
child_name_bindings,
self.session.str_of(ident),
ident,
new_parent);
}
}
}
DlImpl(def) => {
// We only process static methods of impls here.
2013-12-25 14:08:04 -06:00
match csearch::get_type_name_if_impl(self.session.cstore, def) {
None => {}
Some(final_ident) => {
let static_methods_opt =
2013-12-25 14:08:04 -06:00
csearch::get_static_methods_if_impl(self.session.cstore, def);
match static_methods_opt {
Some(ref static_methods) if
static_methods.len() >= 1 => {
debug!("(building reduced graph for \
external crate) processing \
2013-09-28 00:38:08 -05:00
static methods for type name {}",
self.session.str_of(
final_ident));
let (child_name_bindings, new_parent) =
self.add_child(
final_ident,
ModuleReducedGraphParent(root),
OverwriteDuplicates,
DUMMY_SP);
// Process the static methods. First,
// create the module.
let type_module;
match child_name_bindings.type_def.get() {
Some(TypeNsDef {
module_def: Some(module_def),
2013-11-28 14:22:53 -06:00
..
}) => {
// We already have a module. This
// is OK.
type_module = module_def;
// Mark it as an impl module if
// necessary.
type_module.kind.set(ImplModuleKind);
}
Some(_) | None => {
let parent_link =
self.get_parent_link(new_parent,
final_ident);
child_name_bindings.define_module(
parent_link,
Some(def),
ImplModuleKind,
true,
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
true,
DUMMY_SP);
type_module =
child_name_bindings.
get_module();
}
}
// Add each static method to the module.
let new_parent =
ModuleReducedGraphParent(type_module);
for static_method_info in
static_methods.iter() {
let ident = static_method_info.ident;
debug!("(building reduced graph for \
external crate) creating \
2013-09-28 00:38:08 -05:00
static method '{}'",
self.session.str_of(ident));
let (method_name_bindings, _) =
self.add_child(ident,
new_parent,
OverwriteDuplicates,
DUMMY_SP);
let def = DefFn(
static_method_info.def_id,
static_method_info.purity);
method_name_bindings.define_value(
def, DUMMY_SP,
visibility == ast::Public);
}
}
// Otherwise, do nothing.
Some(_) | None => {}
}
}
}
}
DlField => {
debug!("(building reduced graph for external crate) \
ignoring field");
}
}
}
/// Builds the reduced graph rooted at the given external module.
2013-12-19 21:02:22 -06:00
fn populate_external_module(&mut self, module: @Module) {
debug!("(populating external module) attempting to populate {}",
self.module_to_str(module));
let def_id = match module.def_id.get() {
None => {
debug!("(populating external module) ... no def ID!");
return
}
Some(def_id) => def_id,
};
csearch::each_child_of_item(self.session.cstore,
def_id,
|def_like, child_ident, visibility| {
let child_ident_string = token::get_ident(child_ident.name);
debug!("(populating external module) ... found ident: {}",
child_ident_string.get());
self.build_reduced_graph_for_external_crate_def(module,
def_like,
child_ident,
visibility)
});
module.populated.set(true)
}
/// Ensures that the reduced graph rooted at the given external module
/// is built, building it if it is not.
2013-12-19 21:02:22 -06:00
fn populate_module_if_necessary(&mut self, module: @Module) {
if !module.populated.get() {
self.populate_external_module(module)
}
assert!(module.populated.get())
}
/// Builds the reduced graph rooted at the 'use' directive for an external
/// crate.
2013-10-02 07:33:01 -05:00
fn build_reduced_graph_for_external_crate(&mut self,
2013-12-19 21:02:22 -06:00
root: @Module) {
csearch::each_top_level_item_of_crate(self.session.cstore,
root.def_id
.get()
.unwrap()
.crate,
|def_like, ident, visibility| {
self.build_reduced_graph_for_external_crate_def(root,
def_like,
ident,
visibility)
});
}
/// Creates and adds an import directive to the given module.
2013-10-02 07:33:01 -05:00
fn build_import_directive(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
module_path: ~[Ident],
subclass: @ImportDirectiveSubclass,
span: Span,
id: NodeId,
is_public: bool) {
let directive = @ImportDirective::new(module_path,
subclass, span, id,
is_public);
{
let mut imports = module_.imports.borrow_mut();
imports.get().push(directive);
}
// Bump the reference count on the name. Or, if this is a glob, set
// the appropriate flag.
2012-08-06 14:34:08 -05:00
match *subclass {
SingleImport(target, _) => {
debug!("(building import directive) building import \
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
directive: {}::{}",
2013-03-07 17:37:14 -06:00
self.idents_to_str(directive.module_path),
self.session.str_of(target));
let mut import_resolutions = module_.import_resolutions
.borrow_mut();
match import_resolutions.get().find(&target.name) {
2013-03-15 14:24:24 -05:00
Some(&resolution) => {
debug!("(building import directive) bumping \
reference");
resolution.outstanding_references.set(
resolution.outstanding_references.get() + 1);
// the source of this name is different now
resolution.type_id.set(id);
resolution.value_id.set(id);
}
2012-08-20 14:23:37 -05:00
None => {
debug!("(building import directive) creating new");
2013-12-21 19:49:43 -06:00
let resolution = @ImportResolution::new(id, is_public);
resolution.outstanding_references.set(1);
import_resolutions.get().insert(target.name,
resolution);
}
}
}
2012-08-03 21:59:04 -05:00
GlobImport => {
// Set the glob flag. This tells us that we don't know the
// module's exports ahead of time.
module_.glob_count.set(module_.glob_count.get() + 1);
}
}
self.unresolved_imports += 1;
}
// Import resolution
//
// This is a fixed-point algorithm. We resolve imports until our efforts
// are stymied by an unresolved import; then we bail out of the current
// module and continue. We terminate successfully once no more imports
// remain or unsuccessfully when no forward progress in resolving imports
// is made.
/// Resolves all imports for the crate. This method performs the fixed-
/// point iteration.
2013-10-02 07:33:01 -05:00
fn resolve_imports(&mut self) {
let mut i = 0;
let mut prev_unresolved_imports = 0;
loop {
debug!("(resolving imports) iteration {}, {} imports left",
2012-08-22 19:24:52 -05:00
i, self.unresolved_imports);
let module_root = self.graph_root.get_module();
self.resolve_imports_for_module_subtree(module_root);
if self.unresolved_imports == 0 {
debug!("(resolving imports) success");
break;
}
if self.unresolved_imports == prev_unresolved_imports {
self.report_unresolved_imports(module_root);
break;
}
i += 1;
prev_unresolved_imports = self.unresolved_imports;
}
}
/// Attempts to resolve imports for the given module and all of its
/// submodules.
2013-10-02 07:33:01 -05:00
fn resolve_imports_for_module_subtree(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module) {
debug!("(resolving imports for module subtree) resolving {}",
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
self.resolve_imports_for_module(module_);
self.populate_module_if_necessary(module_);
2013-12-21 17:32:44 -06:00
{
let children = module_.children.borrow();
for (_, &child_node) in children.get().iter() {
match child_node.get_module_if_available() {
None => {
// Nothing to do.
}
Some(child_module) => {
self.resolve_imports_for_module_subtree(child_module);
}
}
}
}
let anonymous_children = module_.anonymous_children.borrow();
for (_, &child_module) in anonymous_children.get().iter() {
self.resolve_imports_for_module_subtree(child_module);
}
}
/// Attempts to resolve imports for the given module only.
2013-12-19 21:02:22 -06:00
fn resolve_imports_for_module(&mut self, module: @Module) {
if module.all_imports_resolved() {
debug!("(resolving imports for module) all imports resolved for \
2013-09-28 00:38:08 -05:00
{}",
self.module_to_str(module));
2012-08-01 19:30:05 -05:00
return;
}
let mut imports = module.imports.borrow_mut();
let import_count = imports.get().len();
while module.resolved_import_count.get() < import_count {
let import_index = module.resolved_import_count.get();
let import_directive = imports.get()[import_index];
match self.resolve_import_for_module(module, import_directive) {
2012-08-03 21:59:04 -05:00
Failed => {
// We presumably emitted an error. Continue.
2013-09-28 00:38:08 -05:00
let msg = format!("failed to resolve import `{}`",
self.import_path_to_str(
2013-03-07 17:37:14 -06:00
import_directive.module_path,
*import_directive.subclass));
self.resolve_error(import_directive.span, msg);
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
// Bail out. We'll come around next time.
break;
}
2012-08-03 21:59:04 -05:00
Success(()) => {
// Good. Continue.
}
}
module.resolved_import_count
.set(module.resolved_import_count.get() + 1);
}
}
2013-10-02 07:33:01 -05:00
fn idents_to_str(&mut self, idents: &[Ident]) -> ~str {
let mut first = true;
let mut result = ~"";
for ident in idents.iter() {
if first {
first = false
} else {
result.push_str("::")
}
2013-06-14 21:40:11 -05:00
result.push_str(self.session.str_of(*ident));
};
return result;
2012-07-18 18:18:02 -05:00
}
fn path_idents_to_str(&mut self, path: &Path) -> ~str {
2013-09-01 19:50:59 -05:00
let identifiers: ~[ast::Ident] = path.segments
.iter()
.map(|seg| seg.identifier)
.collect();
self.idents_to_str(identifiers)
}
2013-10-02 07:33:01 -05:00
fn import_directive_subclass_to_str(&mut self,
2014-01-31 14:25:11 -06:00
subclass: ImportDirectiveSubclass)
-> ~str {
match subclass {
2014-01-31 14:25:11 -06:00
SingleImport(_target, source) => {
self.session.str_of(source).to_str()
}
GlobImport => ~"*"
}
}
2013-10-02 07:33:01 -05:00
fn import_path_to_str(&mut self,
2014-01-31 14:25:11 -06:00
idents: &[Ident],
subclass: ImportDirectiveSubclass)
-> ~str {
if idents.is_empty() {
self.import_directive_subclass_to_str(subclass)
} else {
2013-09-28 00:38:08 -05:00
(format!("{}::{}",
2014-01-31 14:25:11 -06:00
self.idents_to_str(idents),
self.import_directive_subclass_to_str(subclass)))
}
}
/// Attempts to resolve the given import. The return value indicates
/// failure if we're certain the name does not exist, indeterminate if we
/// don't know whether the name exists at the moment due to other
/// currently-unresolved imports, or success if we know the name exists.
/// If successful, the resolved bindings are written into the module.
2013-10-02 07:33:01 -05:00
fn resolve_import_for_module(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
import_directive: @ImportDirective)
-> ResolveResult<()> {
let mut resolution_result = Failed;
2013-03-07 17:37:14 -06:00
let module_path = &import_directive.module_path;
debug!("(resolving import for module) resolving import `{}::...` in \
2013-09-28 00:38:08 -05:00
`{}`",
2013-03-07 17:37:14 -06:00
self.idents_to_str(*module_path),
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
// First, resolve the module path for the directive, if necessary.
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
let container = if module_path.len() == 0 {
// Use the crate root.
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
Some((self.graph_root.get_module(), AllPublic))
} else {
match self.resolve_module_path(module_,
*module_path,
DontUseLexicalScope,
import_directive.span,
ImportSearch) {
Failed => None,
2012-08-03 21:59:04 -05:00
Indeterminate => {
resolution_result = Indeterminate;
None
}
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
Success(container) => Some(container),
}
};
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
match container {
None => {}
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
Some((containing_module, lp)) => {
// We found the module that the target is contained
// within. Attempt to resolve the import within it.
match *import_directive.subclass {
SingleImport(target, source) => {
resolution_result =
self.resolve_single_import(module_,
containing_module,
target,
source,
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
import_directive,
lp);
}
GlobImport => {
resolution_result =
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
self.resolve_glob_import(module_,
containing_module,
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
import_directive.id,
import_directive.is_public,
lp);
}
}
}
}
// Decrement the count of unresolved imports.
2012-08-06 14:34:08 -05:00
match resolution_result {
2012-08-03 21:59:04 -05:00
Success(()) => {
2013-03-28 20:39:09 -05:00
assert!(self.unresolved_imports >= 1);
self.unresolved_imports -= 1;
}
2012-08-03 21:59:04 -05:00
_ => {
// Nothing to do here; just return the error.
}
}
// Decrement the count of unresolved globs if necessary. But only if
// the resolution result is indeterminate -- otherwise we'll stop
// processing imports here. (See the loop in
// resolve_imports_for_module.)
if !resolution_result.indeterminate() {
2012-08-06 14:34:08 -05:00
match *import_directive.subclass {
2012-08-03 21:59:04 -05:00
GlobImport => {
assert!(module_.glob_count.get() >= 1);
module_.glob_count.set(module_.glob_count.get() - 1);
}
2013-11-28 14:22:53 -06:00
SingleImport(..) => {
// Ignore.
}
}
}
2012-08-01 19:30:05 -05:00
return resolution_result;
}
2013-12-21 16:20:57 -06:00
fn create_name_bindings_from_module(module: @Module) -> NameBindings {
NameBindings {
type_def: RefCell::new(Some(TypeNsDef {
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
is_public: false,
module_def: Some(module),
type_def: None,
type_span: None
})),
value_def: RefCell::new(None),
}
}
2013-10-02 07:33:01 -05:00
fn resolve_single_import(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
containing_module: @Module,
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
target: Ident,
source: Ident,
directive: &ImportDirective,
lp: LastPrivate)
-> ResolveResult<()> {
debug!("(resolving single import) resolving `{}` = `{}::{}` from \
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
`{}` id {}, last private {:?}",
self.session.str_of(target),
self.module_to_str(containing_module),
self.session.str_of(source),
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
self.module_to_str(module_),
directive.id,
lp);
// We need to resolve both namespaces for this to succeed.
//
let mut value_result = UnknownResult;
let mut type_result = UnknownResult;
// Search for direct children of the containing module.
self.populate_module_if_necessary(containing_module);
2013-12-21 17:32:44 -06:00
{
let children = containing_module.children.borrow();
match children.get().find(&source.name) {
None => {
// Continue.
}
2013-12-21 17:32:44 -06:00
Some(child_name_bindings) => {
if child_name_bindings.defined_in_namespace(ValueNS) {
value_result = BoundResult(containing_module,
*child_name_bindings);
}
if child_name_bindings.defined_in_namespace(TypeNS) {
type_result = BoundResult(containing_module,
*child_name_bindings);
}
}
}
}
// Unless we managed to find a result in both namespaces (unlikely),
// search imports as well.
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
let mut used_reexport = false;
match (value_result, type_result) {
2013-11-28 14:22:53 -06:00
(BoundResult(..), BoundResult(..)) => {} // Continue.
2012-08-03 21:59:04 -05:00
_ => {
// If there is an unresolved glob at this point in the
// containing module, bail out. We don't know enough to be
// able to resolve this import.
if containing_module.glob_count.get() > 0 {
debug!("(resolving single import) unresolved glob; \
2012-08-22 19:24:52 -05:00
bailing out");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
// Now search the exported imports within the containing
// module.
let import_resolutions = containing_module.import_resolutions
.borrow();
match import_resolutions.get().find(&source.name) {
2012-08-20 14:23:37 -05:00
None => {
// The containing module definitely doesn't have an
// exported import with the name in question. We can
// therefore accurately report that the names are
// unbound.
2012-08-27 18:26:35 -05:00
if value_result.is_unknown() {
value_result = UnboundResult;
}
2012-08-27 18:26:35 -05:00
if type_result.is_unknown() {
type_result = UnboundResult;
}
}
2012-08-20 14:23:37 -05:00
Some(import_resolution)
if import_resolution.outstanding_references.get()
== 0 => {
fn get_binding(this: &mut Resolver,
2013-12-21 19:49:43 -06:00
import_resolution: @ImportResolution,
namespace: Namespace)
-> NamespaceResult {
// Import resolutions must be declared with "pub"
// in order to be exported.
if !import_resolution.is_public.get() {
return UnboundResult;
}
2012-08-06 14:34:08 -05:00
match (*import_resolution).
target_for_namespace(namespace) {
2012-08-20 14:23:37 -05:00
None => {
2012-08-01 19:30:05 -05:00
return UnboundResult;
}
2012-08-20 14:23:37 -05:00
Some(target) => {
let id = import_resolution.id(namespace);
this.used_imports.insert(id);
2012-08-01 19:30:05 -05:00
return BoundResult(target.target_module,
target.bindings);
}
}
}
// The name is an import which has been fully
// resolved. We can, therefore, just follow it.
2012-08-27 18:26:35 -05:00
if value_result.is_unknown() {
value_result = get_binding(self, *import_resolution,
ValueNS);
used_reexport = import_resolution.is_public.get();
}
2012-08-27 18:26:35 -05:00
if type_result.is_unknown() {
type_result = get_binding(self, *import_resolution,
TypeNS);
used_reexport = import_resolution.is_public.get();
}
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
}
2012-08-20 14:23:37 -05:00
Some(_) => {
// The import is unresolved. Bail out.
debug!("(resolving single import) unresolved import; \
2012-08-22 19:24:52 -05:00
bailing out");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
}
}
}
// If we didn't find a result in the type namespace, search the
// external modules.
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
let mut used_public = false;
match type_result {
2013-11-28 14:22:53 -06:00
BoundResult(..) => {}
_ => {
let module_opt = {
let mut external_module_children =
containing_module.external_module_children
.borrow_mut();
external_module_children.get().find_copy(&source.name)
};
match module_opt {
None => {} // Continue.
Some(module) => {
let name_bindings =
2013-12-21 16:20:57 -06:00
@Resolver::create_name_bindings_from_module(
module);
type_result = BoundResult(containing_module,
name_bindings);
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
used_public = true;
}
}
}
}
// We've successfully resolved the import. Write the results in.
let import_resolution = {
let import_resolutions = module_.import_resolutions.borrow();
assert!(import_resolutions.get().contains_key(&target.name));
import_resolutions.get().get_copy(&target.name)
};
2012-08-06 14:34:08 -05:00
match value_result {
2012-08-03 21:59:04 -05:00
BoundResult(target_module, name_bindings) => {
debug!("(resolving single import) found value target");
import_resolution.value_target.set(
Some(Target::new(target_module, name_bindings)));
import_resolution.value_id.set(directive.id);
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
used_public = name_bindings.defined_in_public_namespace(ValueNS);
}
2012-08-03 21:59:04 -05:00
UnboundResult => { /* Continue. */ }
UnknownResult => {
fail!("value result should be known at this point");
}
}
2012-08-06 14:34:08 -05:00
match type_result {
2012-08-03 21:59:04 -05:00
BoundResult(target_module, name_bindings) => {
debug!("(resolving single import) found type target: {:?}",
{name_bindings.type_def.get().unwrap().type_def});
import_resolution.type_target.set(
Some(Target::new(target_module, name_bindings)));
import_resolution.type_id.set(directive.id);
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
used_public = name_bindings.defined_in_public_namespace(TypeNS);
}
2012-08-03 21:59:04 -05:00
UnboundResult => { /* Continue. */ }
UnknownResult => {
fail!("type result should be known at this point");
}
}
if import_resolution.value_target.get().is_none() &&
import_resolution.type_target.get().is_none() {
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
let msg = format!("unresolved import: there is no \
`{}` in `{}`",
2013-09-28 00:38:08 -05:00
self.session.str_of(source),
self.module_to_str(containing_module));
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
self.resolve_error(directive.span, msg);
return Failed;
}
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
let used_public = used_reexport || used_public;
assert!(import_resolution.outstanding_references.get() >= 1);
import_resolution.outstanding_references.set(
import_resolution.outstanding_references.get() - 1);
// record what this import resolves to for later uses in documentation,
// this may resolve to either a value or a type, but for documentation
// purposes it's good enough to just favor one over the other.
match import_resolution.value_target.get() {
Some(target) => {
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
let def = target.bindings.def_for_namespace(ValueNS).unwrap();
let mut def_map = self.def_map.borrow_mut();
def_map.get().insert(directive.id, def);
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
let did = def_id_of_def(def);
self.last_private.insert(directive.id,
if used_public {lp} else {DependsOn(did)});
}
None => {}
}
match import_resolution.type_target.get() {
Some(target) => {
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
let def = target.bindings.def_for_namespace(TypeNS).unwrap();
let mut def_map = self.def_map.borrow_mut();
def_map.get().insert(directive.id, def);
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
let did = def_id_of_def(def);
self.last_private.insert(directive.id,
if used_public {lp} else {DependsOn(did)});
}
None => {}
}
debug!("(resolving single import) successfully resolved import");
2012-08-01 19:30:05 -05:00
return Success(());
}
// Resolves a glob import. Note that this function cannot fail; it either
// succeeds or bails out (as importing * from an empty module or a module
// that exports nothing is valid).
2013-10-02 07:33:01 -05:00
fn resolve_glob_import(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
containing_module: @Module,
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
id: NodeId,
is_public: bool,
lp: LastPrivate)
-> ResolveResult<()> {
// This function works in a highly imperative manner; it eagerly adds
// everything it can to the list of import resolutions of the module
// node.
debug!("(resolving glob import) resolving glob import {}", id);
// We must bail out if the node has unresolved imports of any kind
// (including globs).
if !(*containing_module).all_imports_resolved() {
debug!("(resolving glob import) target module has unresolved \
2012-08-22 19:24:52 -05:00
imports; bailing out");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
assert_eq!(containing_module.glob_count.get(), 0);
// Add all resolved imports from the containing module.
let import_resolutions = containing_module.import_resolutions
.borrow();
for (ident, target_import_resolution) in import_resolutions.get()
.iter() {
debug!("(resolving glob import) writing module resolution \
2013-09-28 00:38:08 -05:00
{:?} into `{}`",
target_import_resolution.type_target.get().is_none(),
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
if !target_import_resolution.is_public.get() {
debug!("(resolving glob import) nevermind, just kidding");
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
continue
}
// Here we merge two import resolutions.
let mut import_resolutions = module_.import_resolutions
.borrow_mut();
match import_resolutions.get().find(ident) {
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
None => {
// Simple: just copy the old import resolution.
let new_import_resolution =
2013-12-21 19:49:43 -06:00
@ImportResolution::new(id, is_public);
new_import_resolution.value_target.set(
target_import_resolution.value_target.get());
new_import_resolution.type_target.set(
target_import_resolution.type_target.get());
import_resolutions.get().insert
(*ident, new_import_resolution);
}
2013-03-15 14:24:24 -05:00
Some(&dest_import_resolution) => {
// Merge the two import resolutions at a finer-grained
// level.
match target_import_resolution.value_target.get() {
2012-08-20 14:23:37 -05:00
None => {
// Continue.
}
2013-05-29 18:59:33 -05:00
Some(value_target) => {
dest_import_resolution.value_target.set(
Some(value_target));
}
}
match target_import_resolution.type_target.get() {
2012-08-20 14:23:37 -05:00
None => {
// Continue.
}
2013-05-29 18:59:33 -05:00
Some(type_target) => {
dest_import_resolution.type_target.set(
Some(type_target));
}
}
dest_import_resolution.is_public.set(is_public);
}
}
}
// Add all children from the containing module.
self.populate_module_if_necessary(containing_module);
2013-12-21 17:32:44 -06:00
{
let children = containing_module.children.borrow();
for (&name, name_bindings) in children.get().iter() {
self.merge_import_resolution(module_, containing_module,
id, is_public,
name, *name_bindings);
2013-12-21 17:32:44 -06:00
}
}
// Add external module children from the containing module.
{
let external_module_children =
containing_module.external_module_children.borrow();
for (&name, module) in external_module_children.get().iter() {
let name_bindings =
2013-12-21 16:20:57 -06:00
@Resolver::create_name_bindings_from_module(*module);
self.merge_import_resolution(module_, containing_module,
id, is_public,
name, name_bindings);
}
}
// Record the destination of this import
match containing_module.def_id.get() {
Some(did) => {
let mut def_map = self.def_map.borrow_mut();
def_map.get().insert(id, DefMod(did));
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
self.last_private.insert(id, lp);
}
None => {}
}
debug!("(resolving glob import) successfully resolved import");
2012-08-01 19:30:05 -05:00
return Success(());
}
fn merge_import_resolution(&mut self,
module_: @Module,
containing_module: @Module,
id: NodeId,
is_public: bool,
name: Name,
name_bindings: @NameBindings) {
let dest_import_resolution;
let mut import_resolutions = module_.import_resolutions.borrow_mut();
match import_resolutions.get().find(&name) {
None => {
// Create a new import resolution from this child.
dest_import_resolution =
@ImportResolution::new(id, is_public);
import_resolutions.get().insert(name,
dest_import_resolution);
}
Some(&existing_import_resolution) => {
dest_import_resolution = existing_import_resolution;
}
}
debug!("(resolving glob import) writing resolution `{}` in `{}` \
to `{}`",
token::get_ident(name).get().to_str(),
self.module_to_str(containing_module),
self.module_to_str(module_));
// Merge the child item into the import resolution.
if name_bindings.defined_in_public_namespace(ValueNS) {
debug!("(resolving glob import) ... for value target");
dest_import_resolution.value_target.set(
Some(Target::new(containing_module, name_bindings)));
dest_import_resolution.value_id.set(id);
}
if name_bindings.defined_in_public_namespace(TypeNS) {
debug!("(resolving glob import) ... for type target");
dest_import_resolution.type_target.set(
Some(Target::new(containing_module, name_bindings)));
dest_import_resolution.type_id.set(id);
}
dest_import_resolution.is_public.set(is_public);
}
/// Resolves the given module path from the given root `module_`.
2013-10-02 07:33:01 -05:00
fn resolve_module_path_from_root(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
module_path: &[Ident],
index: uint,
span: Span,
name_search_type: NameSearchType,
lp: LastPrivate)
2013-12-19 21:02:22 -06:00
-> ResolveResult<(@Module, LastPrivate)> {
let mut search_module = module_;
let mut index = index;
2013-03-07 17:37:14 -06:00
let module_path_len = module_path.len();
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
let mut closest_private = lp;
// Resolve the module part of the path. This does not involve looking
// upward though scope chains; we simply resolve names directly in
// modules as we go.
while index < module_path_len {
2013-03-07 17:37:14 -06:00
let name = module_path[index];
match self.resolve_name_in_module(search_module,
name,
TypeNS,
name_search_type) {
2012-08-03 21:59:04 -05:00
Failed => {
let segment_name = self.session.str_of(name);
let module_name = self.module_to_str(search_module);
if "???" == module_name {
let span = Span {
lo: span.lo,
2013-11-19 11:15:49 -06:00
hi: span.lo + Pos::from_uint(segment_name.len()),
expn_info: span.expn_info,
};
self.resolve_error(span,
2013-09-28 00:38:08 -05:00
format!("unresolved import. maybe \
a missing `extern mod \
2013-09-28 00:38:08 -05:00
{}`?",
segment_name));
return Failed;
}
2013-09-28 00:38:08 -05:00
self.resolve_error(span, format!("unresolved import: could not find `{}` in \
`{}`.", segment_name, module_name));
2012-08-01 19:30:05 -05:00
return Failed;
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
debug!("(resolving module path for import) module \
2013-09-28 00:38:08 -05:00
resolution is indeterminate: {}",
self.session.str_of(name));
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
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
Success((target, used_proxy)) => {
// Check to see whether there are type bindings, and, if
// so, whether there is a module within.
match target.bindings.type_def.get() {
2013-05-29 18:59:33 -05:00
Some(type_def) => {
match type_def.module_def {
None => {
// Not a module.
self.resolve_error(span,
2013-09-28 00:38:08 -05:00
format!("not a \
module `{}`",
self.session.
str_of(
name)));
return Failed;
}
Some(module_def) => {
// If we're doing the search for an
// import, do not allow traits and impls
// to be selected.
match (name_search_type,
module_def.kind.get()) {
(ImportSearch, TraitModuleKind) |
(ImportSearch, ImplModuleKind) => {
self.resolve_error(
span,
2013-05-23 11:39:10 -05:00
"cannot import from a trait \
or type implementation");
return Failed;
}
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
(_, _) => {
search_module = module_def;
// Keep track of the closest
// private module used when
// resolving this import chain.
if !used_proxy &&
!search_module.is_public {
match search_module.def_id
.get() {
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
Some(did) => {
closest_private =
DependsOn(did);
}
None => {}
}
}
}
}
}
}
}
None => {
// There are no type bindings at all.
self.resolve_error(span,
2013-09-28 00:38:08 -05:00
format!("not a module `{}`",
self.session.str_of(
name)));
2012-08-01 19:30:05 -05:00
return Failed;
}
}
}
}
index += 1;
}
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
return Success((search_module, closest_private));
}
/// Attempts to resolve the module part of an import directive or path
/// rooted at the given module.
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
///
/// On success, returns the resolved module, and the closest *private*
/// module found to the destination when resolving this path.
2013-10-02 07:33:01 -05:00
fn resolve_module_path(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
module_path: &[Ident],
use_lexical_scope: UseLexicalScopeFlag,
span: Span,
name_search_type: NameSearchType)
2013-12-19 21:02:22 -06:00
-> ResolveResult<(@Module, LastPrivate)> {
let module_path_len = module_path.len();
2013-03-28 20:39:09 -05:00
assert!(module_path_len > 0);
debug!("(resolving module path for import) processing `{}` rooted at \
2013-09-28 00:38:08 -05:00
`{}`",
2013-03-07 17:37:14 -06:00
self.idents_to_str(module_path),
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
// Resolve the module prefix, if any.
let module_prefix_result = self.resolve_module_prefix(module_,
module_path);
2013-04-12 00:15:30 -05:00
let search_module;
let start_index;
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
let last_private;
match module_prefix_result {
2012-08-03 21:59:04 -05:00
Failed => {
let mpath = self.idents_to_str(module_path);
match mpath.rfind(':') {
2013-05-14 18:49:04 -05:00
Some(idx) => {
2013-09-28 00:38:08 -05:00
self.resolve_error(span, format!("unresolved import: could not find `{}` \
in `{}`",
// idx +- 1 to account for the colons
// on either side
mpath.slice_from(idx + 1),
mpath.slice_to(idx - 1)));
2013-05-14 18:49:04 -05:00
},
None => (),
};
2012-08-01 19:30:05 -05:00
return Failed;
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
debug!("(resolving module path for import) indeterminate; \
2012-08-22 19:24:52 -05:00
bailing");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
Success(NoPrefixFound) => {
// There was no prefix, so we're considering the first element
// of the path. How we handle this depends on whether we were
// instructed to use lexical scope or not.
match use_lexical_scope {
DontUseLexicalScope => {
// This is a crate-relative path. We will start the
// resolution process at index zero.
search_module = self.graph_root.get_module();
start_index = 0;
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
last_private = AllPublic;
}
UseLexicalScope => {
// This is not a crate-relative path. We resolve the
// first component of the path in the current lexical
// scope and then proceed to resolve below that.
let result = self.resolve_module_in_lexical_scope(
module_,
2013-03-07 17:37:14 -06:00
module_path[0]);
match result {
Failed => {
self.resolve_error(span, "unresolved name");
return Failed;
}
Indeterminate => {
debug!("(resolving module path for import) \
indeterminate; bailing");
return Indeterminate;
}
Success(containing_module) => {
search_module = containing_module;
start_index = 1;
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
last_private = AllPublic;
}
}
}
}
}
Success(PrefixFound(containing_module, index)) => {
search_module = containing_module;
start_index = index;
last_private = DependsOn(containing_module.def_id
.get()
.unwrap());
}
}
self.resolve_module_path_from_root(search_module,
module_path,
start_index,
span,
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
name_search_type,
last_private)
}
/// Invariant: This must only be called during main resolution, not during
/// import resolution.
2013-10-02 07:33:01 -05:00
fn resolve_item_in_lexical_scope(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
name: Ident,
namespace: Namespace,
search_through_modules:
SearchThroughModulesFlag)
-> ResolveResult<(Target, bool)> {
debug!("(resolving item in lexical scope) resolving `{}` in \
2013-09-28 00:38:08 -05:00
namespace {:?} in `{}`",
self.session.str_of(name),
namespace,
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
// The current module node is handled specially. First, check for
// its immediate children.
self.populate_module_if_necessary(module_);
2013-12-21 17:32:44 -06:00
{
let children = module_.children.borrow();
match children.get().find(&name.name) {
Some(name_bindings)
if name_bindings.defined_in_namespace(namespace) => {
debug!("top name bindings succeeded");
return Success((Target::new(module_, *name_bindings),
false));
}
Some(_) | None => { /* Not found; continue. */ }
}
}
// Now check for its import directives. We don't have to have resolved
// all its imports in the usual way; this is because chains of
// adjacent import statements are processed as though they mutated the
// current scope.
let import_resolutions = module_.import_resolutions.borrow();
match import_resolutions.get().find(&name.name) {
2012-08-20 14:23:37 -05:00
None => {
// Not found; continue.
}
2012-08-20 14:23:37 -05:00
Some(import_resolution) => {
2012-08-06 14:34:08 -05:00
match (*import_resolution).target_for_namespace(namespace) {
2012-08-20 14:23:37 -05:00
None => {
// Not found; continue.
debug!("(resolving item in lexical scope) found \
2013-09-28 00:38:08 -05:00
import resolution, but not in namespace {:?}",
2012-08-22 19:24:52 -05:00
namespace);
}
2012-08-20 14:23:37 -05:00
Some(target) => {
debug!("(resolving item in lexical scope) using \
import resolution");
self.used_imports.insert(import_resolution.id(namespace));
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
return Success((target, false));
}
}
}
}
// Search for external modules.
if namespace == TypeNS {
let module_opt = {
let external_module_children =
module_.external_module_children.borrow();
external_module_children.get().find_copy(&name.name)
};
match module_opt {
None => {}
Some(module) => {
let name_bindings =
2013-12-21 16:20:57 -06:00
@Resolver::create_name_bindings_from_module(module);
debug!("lower name bindings succeeded");
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
return Success((Target::new(module_, name_bindings), false));
}
}
}
// Finally, proceed up the scope chain looking for parent modules.
let mut search_module = module_;
loop {
// Go to the next parent.
2012-08-06 14:34:08 -05:00
match search_module.parent_link {
2012-08-03 21:59:04 -05:00
NoParentLink => {
// No more parents. This module was unresolved.
debug!("(resolving item in lexical scope) unresolved \
2012-08-22 19:24:52 -05:00
module");
2012-08-01 19:30:05 -05:00
return Failed;
}
ModuleParentLink(parent_module_node, _) => {
match search_through_modules {
DontSearchThroughModules => {
match search_module.kind.get() {
NormalModuleKind => {
// We stop the search here.
debug!("(resolving item in lexical \
scope) unresolved module: not \
searching through module \
parents");
return Failed;
}
ExternModuleKind |
TraitModuleKind |
ImplModuleKind |
AnonymousModuleKind => {
search_module = parent_module_node;
}
}
}
SearchThroughModules => {
search_module = parent_module_node;
}
}
}
2012-08-03 21:59:04 -05:00
BlockParentLink(parent_module_node, _) => {
search_module = parent_module_node;
}
}
// Resolve the name in the parent module.
match self.resolve_name_in_module(search_module,
name,
namespace,
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
PathSearch) {
2012-08-03 21:59:04 -05:00
Failed => {
// Continue up the search chain.
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
// We couldn't see through the higher scope because of an
// unresolved import higher up. Bail.
debug!("(resolving item in lexical scope) indeterminate \
2012-08-22 19:24:52 -05:00
higher scope; bailing");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
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
Success((target, used_reexport)) => {
// We found the module.
debug!("(resolving item in lexical scope) found name \
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
in module, done");
return Success((target, used_reexport));
}
}
}
}
/// Resolves a module name in the current lexical scope.
2013-10-02 07:33:01 -05:00
fn resolve_module_in_lexical_scope(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
name: Ident)
2013-12-19 21:02:22 -06:00
-> ResolveResult<@Module> {
// If this module is an anonymous module, resolve the item in the
// lexical scope. Otherwise, resolve the item from the crate root.
let resolve_result = self.resolve_item_in_lexical_scope(
module_, name, TypeNS, DontSearchThroughModules);
match resolve_result {
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
Success((target, _)) => {
2013-12-21 16:20:57 -06:00
let bindings = &*target.bindings;
match bindings.type_def.get() {
Some(type_def) => {
match type_def.module_def {
None => {
error!("!!! (resolving module in lexical \
scope) module wasn't actually a \
module!");
return Failed;
}
Some(module_def) => {
return Success(module_def);
}
}
}
None => {
error!("!!! (resolving module in lexical scope) module
2012-08-22 19:24:52 -05:00
wasn't actually a module!");
2012-08-01 19:30:05 -05:00
return Failed;
}
}
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
debug!("(resolving module in lexical scope) indeterminate; \
2012-08-22 19:24:52 -05:00
bailing");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
2012-08-03 21:59:04 -05:00
Failed => {
debug!("(resolving module in lexical scope) failed to \
2012-08-22 19:24:52 -05:00
resolve");
2012-08-01 19:30:05 -05:00
return Failed;
}
}
}
/// Returns the nearest normal module parent of the given module.
2013-12-19 21:02:22 -06:00
fn get_nearest_normal_module_parent(&mut self, module_: @Module)
-> Option<@Module> {
let mut module_ = module_;
loop {
match module_.parent_link {
NoParentLink => return None,
ModuleParentLink(new_module, _) |
BlockParentLink(new_module, _) => {
match new_module.kind.get() {
NormalModuleKind => return Some(new_module),
ExternModuleKind |
TraitModuleKind |
ImplModuleKind |
AnonymousModuleKind => module_ = new_module,
}
}
}
}
}
/// Returns the nearest normal module parent of the given module, or the
/// module itself if it is a normal module.
2013-12-19 21:02:22 -06:00
fn get_nearest_normal_module_parent_or_self(&mut self, module_: @Module)
-> @Module {
match module_.kind.get() {
NormalModuleKind => return module_,
ExternModuleKind |
TraitModuleKind |
ImplModuleKind |
AnonymousModuleKind => {
match self.get_nearest_normal_module_parent(module_) {
None => module_,
Some(new_module) => new_module
}
}
}
}
/// Resolves a "module prefix". A module prefix is one or both of (a) `self::`;
/// (b) some chain of `super::`.
/// grammar: (SELF MOD_SEP ) ? (SUPER MOD_SEP) *
2013-10-02 07:33:01 -05:00
fn resolve_module_prefix(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
module_path: &[Ident])
-> ResolveResult<ModulePrefixResult> {
// Start at the current module if we see `self` or `super`, or at the
// top of the crate otherwise.
let mut containing_module;
let mut i;
let first_module_path_string = token::get_ident(module_path[0].name);
if "self" == first_module_path_string.get() {
containing_module =
self.get_nearest_normal_module_parent_or_self(module_);
i = 1;
} else if "super" == first_module_path_string.get() {
containing_module =
self.get_nearest_normal_module_parent_or_self(module_);
i = 0; // We'll handle `super` below.
} else {
return Success(NoPrefixFound);
}
// Now loop through all the `super`s we find.
while i < module_path.len() {
let string = token::get_ident(module_path[i].name);
if "super" != string.get() {
break
}
debug!("(resolving module prefix) resolving `super` at {}",
self.module_to_str(containing_module));
match self.get_nearest_normal_module_parent(containing_module) {
None => return Failed,
Some(new_module) => {
containing_module = new_module;
i += 1;
}
}
}
debug!("(resolving module prefix) finished resolving prefix at {}",
self.module_to_str(containing_module));
return Success(PrefixFound(containing_module, i));
}
/// Attempts to resolve the supplied name in the given module for the
/// given namespace. If successful, returns the target corresponding to
/// the name.
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
///
/// The boolean returned on success is an indicator of whether this lookup
/// passed through a public re-export proxy.
2013-10-02 07:33:01 -05:00
fn resolve_name_in_module(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module,
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
name: Ident,
namespace: Namespace,
name_search_type: NameSearchType)
-> ResolveResult<(Target, bool)> {
debug!("(resolving name in module) resolving `{}` in `{}`",
self.session.str_of(name),
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
// First, check the direct children of the module.
self.populate_module_if_necessary(module_);
2013-12-21 17:32:44 -06:00
{
let children = module_.children.borrow();
match children.get().find(&name.name) {
Some(name_bindings)
if name_bindings.defined_in_namespace(namespace) => {
debug!("(resolving name in module) found node as child");
return Success((Target::new(module_, *name_bindings),
false));
}
Some(_) | None => {
// Continue.
}
}
}
// Next, check the module's imports if necessary.
// If this is a search of all imports, we should be done with glob
// resolution at this point.
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
if name_search_type == PathSearch {
assert_eq!(module_.glob_count.get(), 0);
}
// Check the list of resolved imports.
let import_resolutions = module_.import_resolutions.borrow();
match import_resolutions.get().find(&name.name) {
2012-08-20 14:23:37 -05:00
Some(import_resolution) => {
if import_resolution.is_public.get() &&
import_resolution.outstanding_references.get() != 0 {
debug!("(resolving name in module) import \
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
unresolved; bailing out");
2012-08-01 19:30:05 -05:00
return Indeterminate;
}
match import_resolution.target_for_namespace(namespace) {
2012-08-20 14:23:37 -05:00
None => {
debug!("(resolving name in module) name found, \
2013-09-28 00:38:08 -05:00
but not in namespace {:?}",
2012-08-22 19:24:52 -05:00
namespace);
}
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
Some(target) => {
debug!("(resolving name in module) resolved to \
2012-08-22 19:24:52 -05:00
import");
self.used_imports.insert(import_resolution.id(namespace));
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
return Success((target, true));
}
}
}
None => {} // Continue.
}
// Finally, search through external children.
if namespace == TypeNS {
let module_opt = {
let external_module_children =
module_.external_module_children.borrow();
external_module_children.get().find_copy(&name.name)
};
match module_opt {
None => {}
Some(module) => {
let name_bindings =
2013-12-21 16:20:57 -06:00
@Resolver::create_name_bindings_from_module(module);
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
return Success((Target::new(module_, name_bindings), false));
}
}
}
// We're out of luck.
debug!("(resolving name in module) failed to resolve `{}`",
self.session.str_of(name));
2012-08-01 19:30:05 -05:00
return Failed;
}
2013-12-19 21:02:22 -06:00
fn report_unresolved_imports(&mut self, module_: @Module) {
let index = module_.resolved_import_count.get();
let mut imports = module_.imports.borrow_mut();
let import_count = imports.get().len();
if index != import_count {
let sn = self.session
.codemap
.span_to_snippet(imports.get()[index].span)
.unwrap();
if sn.contains("::") {
self.resolve_error(imports.get()[index].span,
"unresolved import");
} else {
2013-09-28 00:38:08 -05:00
let err = format!("unresolved import (maybe you meant `{}::*`?)",
sn.slice(0, sn.len()));
self.resolve_error(imports.get()[index].span, err);
}
}
// Descend into children and anonymous children.
self.populate_module_if_necessary(module_);
2013-12-21 17:32:44 -06:00
{
let children = module_.children.borrow();
for (_, &child_node) in children.get().iter() {
match child_node.get_module_if_available() {
None => {
// Continue.
}
Some(child_module) => {
self.report_unresolved_imports(child_module);
}
}
}
}
let anonymous_children = module_.anonymous_children.borrow();
for (_, &module_) in anonymous_children.get().iter() {
self.report_unresolved_imports(module_);
}
}
// Export recording
//
// This pass simply determines what all "export" keywords refer to and
// writes the results into the export map.
//
// FIXME #4953 This pass will be removed once exports change to per-item.
// Then this operation can simply be performed as part of item (or import)
// processing.
2013-10-02 07:33:01 -05:00
fn record_exports(&mut self) {
let root_module = self.graph_root.get_module();
self.record_exports_for_module_subtree(root_module);
}
2013-10-02 07:33:01 -05:00
fn record_exports_for_module_subtree(&mut self,
2013-12-19 21:02:22 -06:00
module_: @Module) {
// If this isn't a local crate, then bail out. We don't need to record
// exports for nonlocal crates.
match module_.def_id.get() {
Some(def_id) if def_id.crate == LOCAL_CRATE => {
// OK. Continue.
debug!("(recording exports for module subtree) recording \
2013-09-28 00:38:08 -05:00
exports for local module `{}`",
self.module_to_str(module_));
}
2012-08-20 14:23:37 -05:00
None => {
// Record exports for the root module.
debug!("(recording exports for module subtree) recording \
2013-09-28 00:38:08 -05:00
exports for root module `{}`",
self.module_to_str(module_));
}
2012-08-20 14:23:37 -05:00
Some(_) => {
// Bail out.
debug!("(recording exports for module subtree) not recording \
2013-09-28 00:38:08 -05:00
exports for `{}`",
2012-08-22 19:24:52 -05:00
self.module_to_str(module_));
2012-08-01 19:30:05 -05:00
return;
}
}
self.record_exports_for_module(module_);
self.populate_module_if_necessary(module_);
2013-12-21 17:32:44 -06:00
{
let children = module_.children.borrow();
for (_, &child_name_bindings) in children.get().iter() {
match child_name_bindings.get_module_if_available() {
None => {
// Nothing to do.
}
Some(child_module) => {
self.record_exports_for_module_subtree(child_module);
}
}
}
}
let anonymous_children = module_.anonymous_children.borrow();
for (_, &child_module) in anonymous_children.get().iter() {
self.record_exports_for_module_subtree(child_module);
}
}
2013-12-19 21:02:22 -06:00
fn record_exports_for_module(&mut self, module_: @Module) {
let mut exports2 = ~[];
self.add_exports_for_module(&mut exports2, module_);
match module_.def_id.get() {
Some(def_id) => {
2013-12-20 23:14:25 -06:00
let mut export_map2 = self.export_map2.borrow_mut();
export_map2.get().insert(def_id.node, exports2);
debug!("(computing exports) writing exports for {} (some)",
def_id.node);
}
None => {}
}
}
2013-10-02 07:33:01 -05:00
fn add_exports_of_namebindings(&mut self,
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
exports2: &mut ~[Export2],
name: Name,
2013-12-21 16:20:57 -06:00
namebindings: @NameBindings,
2014-01-24 05:46:19 -06:00
ns: Namespace) {
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
match namebindings.def_for_namespace(ns) {
Some(d) => {
2014-01-24 05:46:19 -06:00
debug!("(computing exports) YES: export '{}' => {:?}",
2014-01-31 14:25:11 -06:00
token::get_ident(name).get().to_str(),
def_id_of_def(d));
exports2.push(Export2 {
2014-01-31 14:25:11 -06:00
name: token::get_ident(name).get().to_str(),
def_id: def_id_of_def(d)
});
}
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
d_opt => {
2014-01-24 05:46:19 -06:00
debug!("(computing exports) NO: {:?}", d_opt);
}
}
}
2013-10-02 07:33:01 -05:00
fn add_exports_for_module(&mut self,
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
exports2: &mut ~[Export2],
2013-12-19 21:02:22 -06:00
module_: @Module) {
let import_resolutions = module_.import_resolutions.borrow();
for (name, importresolution) in import_resolutions.get().iter() {
if !importresolution.is_public.get() {
continue
}
let xs = [TypeNS, ValueNS];
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
for &ns in xs.iter() {
match importresolution.target_for_namespace(ns) {
Some(target) => {
2014-01-24 05:46:19 -06:00
debug!("(computing exports) maybe export '{}'",
2014-01-31 14:25:11 -06:00
token::get_ident(*name).get().to_str());
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
self.add_exports_of_namebindings(exports2,
*name,
target.bindings,
2014-01-24 05:46:19 -06:00
ns)
}
_ => ()
}
}
}
}
// AST resolution
//
// We maintain a list of value ribs and type ribs.
//
// Simultaneously, we keep track of the current position in the module
// graph in the `current_module` pointer. When we go to resolve a name in
// the value or type namespaces, we first look through all the ribs and
// then query the module graph. When we resolve a name in the module
// namespace, we can skip all the ribs (since nested modules are not
// allowed within blocks in Rust) and jump straight to the current module
// graph node.
//
// Named implementations are handled separately. When we find a method
// call, we consult the module node to find all of the implementations in
// scope. This information is lazily cached in the module node. We then
// generate a fake "implementation scope" containing all the
// implementations thus found, for compatibility with old resolve pass.
fn with_scope(&mut self, name: Option<Ident>, f: |&mut Resolver|) {
let orig_module = self.current_module;
// Move down in the graph.
2012-08-06 14:34:08 -05:00
match name {
2012-08-20 14:23:37 -05:00
None => {
// Nothing to do.
}
2012-08-20 14:23:37 -05:00
Some(name) => {
self.populate_module_if_necessary(orig_module);
2013-12-21 17:32:44 -06:00
let children = orig_module.children.borrow();
match children.get().find(&name.name) {
2012-08-20 14:23:37 -05:00
None => {
debug!("!!! (with scope) didn't find `{}` in `{}`",
self.session.str_of(name),
2012-08-22 19:24:52 -05:00
self.module_to_str(orig_module));
}
2012-08-20 14:23:37 -05:00
Some(name_bindings) => {
2012-08-06 14:34:08 -05:00
match (*name_bindings).get_module_if_available() {
2012-08-20 14:23:37 -05:00
None => {
debug!("!!! (with scope) didn't find module \
2013-09-28 00:38:08 -05:00
for `{}` in `{}`",
self.session.str_of(name),
2012-08-22 19:24:52 -05:00
self.module_to_str(orig_module));
}
2012-08-20 14:23:37 -05:00
Some(module_) => {
self.current_module = module_;
}
}
}
}
}
}
f(self);
self.current_module = orig_module;
}
/// Wraps the given definition in the appropriate number of `def_upvar`
/// wrappers.
2013-10-02 07:33:01 -05:00
fn upvarify(&mut self,
ribs: &mut ~[@Rib],
rib_index: uint,
def_like: DefLike,
span: Span)
-> Option<DefLike> {
let mut def;
2013-04-12 00:15:30 -05:00
let is_ty_param;
2012-08-06 14:34:08 -05:00
match def_like {
2013-11-28 14:22:53 -06:00
DlDef(d @ DefLocal(..)) | DlDef(d @ DefUpvar(..)) |
DlDef(d @ DefArg(..)) | DlDef(d @ DefBinding(..)) => {
def = d;
is_ty_param = false;
}
2013-11-28 14:22:53 -06:00
DlDef(d @ DefTyParam(..)) => {
def = d;
is_ty_param = true;
}
2012-08-03 21:59:04 -05:00
_ => {
2012-08-20 14:23:37 -05:00
return Some(def_like);
}
}
let mut rib_index = rib_index + 1;
2013-03-07 17:37:14 -06:00
while rib_index < ribs.len() {
match ribs[rib_index].kind {
2012-08-03 21:59:04 -05:00
NormalRibKind => {
// Nothing to do. Continue.
}
FunctionRibKind(function_id, body_id) => {
if !is_ty_param {
def = DefUpvar(def_id_of_def(def).node,
@def,
function_id,
body_id);
}
}
2012-08-26 14:12:05 -05:00
MethodRibKind(item_id, _) => {
// If the def is a ty param, and came from the parent
// item, it's ok
2012-08-06 14:34:08 -05:00
match def {
DefTyParam(did, _) if {
let def_map = self.def_map.borrow();
def_map.get().find(&did.node).map(|x| *x)
== Some(DefTyParamBinder(item_id))
} => {
// ok
}
2012-08-03 21:59:04 -05:00
_ => {
if !is_ty_param {
// This was an attempt to access an upvar inside a
// named function item. This is not allowed, so we
// report an error.
self.resolve_error(
span,
"can't capture dynamic environment in a fn item; \
use the || { ... } closure form instead");
} else {
// This was an attempt to use a type parameter outside
// its scope.
self.resolve_error(span,
"attempt to use a type \
argument out of scope");
}
2012-08-20 14:23:37 -05:00
return None;
}
}
}
2012-08-03 21:59:04 -05:00
OpaqueFunctionRibKind => {
if !is_ty_param {
// This was an attempt to access an upvar inside a
// named function item. This is not allowed, so we
// report an error.
self.resolve_error(
span,
"can't capture dynamic environment in a fn item; \
use the || { ... } closure form instead");
} else {
// This was an attempt to use a type parameter outside
// its scope.
self.resolve_error(span,
"attempt to use a type \
argument out of scope");
}
2012-08-20 14:23:37 -05:00
return None;
}
ConstantItemRibKind => {
if is_ty_param {
// see #9186
self.resolve_error(span,
"cannot use an outer type \
parameter in this context");
} else {
// Still doesn't deal with upvars
self.resolve_error(span,
"attempt to use a non-constant \
value in a constant");
}
}
}
rib_index += 1;
}
return Some(DlDef(def));
}
2013-10-02 07:33:01 -05:00
fn search_ribs(&mut self,
ribs: &mut ~[@Rib],
name: Name,
span: Span)
-> Option<DefLike> {
// FIXME #4950: This should not use a while loop.
// FIXME #4950: Try caching?
2013-03-07 17:37:14 -06:00
let mut i = ribs.len();
while i != 0 {
i -= 1;
2013-12-21 15:58:11 -06:00
let binding_opt = {
let bindings = ribs[i].bindings.borrow();
bindings.get().find_copy(&name)
};
match binding_opt {
Some(def_like) => {
return self.upvarify(ribs, i, def_like, span);
}
2012-08-20 14:23:37 -05:00
None => {
// Continue.
}
}
}
2012-08-20 14:23:37 -05:00
return None;
}
2013-10-02 07:33:01 -05:00
fn resolve_crate(&mut self, crate: &ast::Crate) {
debug!("(resolving crate) starting");
2013-09-27 21:46:09 -05:00
visit::walk_crate(self, crate, ());
}
fn resolve_item(&mut self, item: &Item) {
debug!("(resolving item) resolving {}",
self.session.str_of(item.ident));
match item.node {
// enum item: resolve all the variants' discrs,
// then resolve the ty params
ItemEnum(ref enum_def, ref generics) => {
for variant in (*enum_def).variants.iter() {
for dis_expr in variant.node.disr_expr.iter() {
// resolve the discriminator expr
// as a constant
self.with_constant_rib(|this| {
this.resolve_expr(*dis_expr);
});
}
}
// n.b. the discr expr gets visted twice.
// but maybe it's okay since the first time will signal an
// error if there is one? -- tjc
self.with_type_parameter_rib(HasTypeParameters(generics,
item.id,
0,
NormalRibKind),
|this| {
visit::walk_item(this, item, ());
});
}
2012-10-15 15:14:23 -05:00
ItemTy(_, ref generics) => {
self.with_type_parameter_rib(HasTypeParameters(generics,
item.id,
0,
NormalRibKind),
|this| {
visit::walk_item(this, item, ());
});
}
ItemImpl(ref generics,
ref implemented_traits,
self_type,
ref methods) => {
self.resolve_implementation(item.id,
generics,
implemented_traits,
self_type,
*methods);
}
ItemTrait(ref generics, ref traits, ref methods) => {
// Create a new rib for the self type.
let self_type_rib = @Rib::new(NormalRibKind);
{
let mut type_ribs = self.type_ribs.borrow_mut();
type_ribs.get().push(self_type_rib);
}
// plain insert (no renaming)
let name = self.type_self_ident.name;
2013-12-21 15:58:11 -06:00
{
let mut bindings = self_type_rib.bindings.borrow_mut();
bindings.get().insert(name, DlDef(DefSelfTy(item.id)));
}
// Create a new rib for the trait-wide type parameters.
self.with_type_parameter_rib(HasTypeParameters(generics,
item.id,
0,
NormalRibKind),
|this| {
this.resolve_type_parameters(&generics.ty_params);
// Resolve derived traits.
for trt in traits.iter() {
this.resolve_trait_reference(item.id, trt, TraitDerivation);
}
for method in (*methods).iter() {
// Create a new rib for the method-specific type
// parameters.
//
// FIXME #4951: Do we need a node ID here?
match *method {
ast::Required(ref ty_m) => {
this.with_type_parameter_rib
(HasTypeParameters(&ty_m.generics,
item.id,
generics.ty_params.len(),
MethodRibKind(item.id, Required)),
|this| {
// Resolve the method-specific type
// parameters.
this.resolve_type_parameters(
&ty_m.generics.ty_params);
for argument in ty_m.decl.inputs.iter() {
this.resolve_type(argument.ty);
}
this.resolve_type(ty_m.decl.output);
});
}
ast::Provided(m) => {
this.resolve_method(MethodRibKind(item.id,
Provided(m.id)),
m,
generics.ty_params.len())
}
}
}
});
let mut type_ribs = self.type_ribs.borrow_mut();
type_ribs.get().pop();
}
ItemStruct(ref struct_def, ref generics) => {
self.resolve_struct(item.id,
generics,
struct_def.fields);
}
ItemMod(ref module_) => {
self.with_scope(Some(item.ident), |this| {
this.resolve_module(module_, item.span, item.ident,
item.id);
});
}
ItemForeignMod(ref foreign_module) => {
self.with_scope(Some(item.ident), |this| {
for foreign_item in foreign_module.items.iter() {
match foreign_item.node {
ForeignItemFn(_, ref generics) => {
this.with_type_parameter_rib(
HasTypeParameters(
generics, foreign_item.id, 0,
NormalRibKind),
|this| visit::walk_foreign_item(this,
*foreign_item,
()));
}
ForeignItemStatic(..) => {
visit::walk_foreign_item(this,
*foreign_item,
());
}
}
}
});
}
ItemFn(fn_decl, _, _, ref generics, block) => {
self.resolve_function(OpaqueFunctionRibKind,
Some(fn_decl),
HasTypeParameters
(generics,
item.id,
0,
OpaqueFunctionRibKind),
block);
}
ItemStatic(..) => {
self.with_constant_rib(|this| {
visit::walk_item(this, item, ());
});
}
2013-12-25 12:10:33 -06:00
ItemMac(..) => {
// do nothing, these are just around to be encoded
}
}
}
2013-10-02 07:33:01 -05:00
fn with_type_parameter_rib(&mut self,
type_parameters: TypeParameters,
f: |&mut Resolver|) {
2012-08-06 14:34:08 -05:00
match type_parameters {
HasTypeParameters(generics, node_id, initial_index,
2012-08-03 21:59:04 -05:00
rib_kind) => {
let function_type_rib = @Rib::new(rib_kind);
{
let mut type_ribs = self.type_ribs.borrow_mut();
type_ribs.get().push(function_type_rib);
}
for (index, type_parameter) in generics.ty_params.iter().enumerate() {
2013-06-05 21:49:41 -05:00
let ident = type_parameter.ident;
debug!("with_type_parameter_rib: {} {}", node_id,
2012-08-22 19:24:52 -05:00
type_parameter.id);
let def_like = DlDef(DefTyParam
(local_def(type_parameter.id),
index + initial_index));
// Associate this type parameter with
// the item that bound it
self.record_def(type_parameter.id,
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
(DefTyParamBinder(node_id), AllPublic));
// plain insert (no renaming)
2013-12-21 15:58:11 -06:00
let mut bindings = function_type_rib.bindings
.borrow_mut();
bindings.get().insert(ident.name, def_like);
}
}
2012-08-03 21:59:04 -05:00
NoTypeParameters => {
// Nothing to do.
}
}
f(self);
2012-08-06 14:34:08 -05:00
match type_parameters {
2013-11-28 14:22:53 -06:00
HasTypeParameters(..) => {
let mut type_ribs = self.type_ribs.borrow_mut();
type_ribs.get().pop();
}
NoTypeParameters => {
// Nothing to do.
}
}
}
fn with_label_rib(&mut self, f: |&mut Resolver|) {
{
let mut label_ribs = self.label_ribs.borrow_mut();
label_ribs.get().push(@Rib::new(NormalRibKind));
}
f(self);
{
let mut label_ribs = self.label_ribs.borrow_mut();
label_ribs.get().pop();
}
}
2013-02-21 13:08:50 -06:00
fn with_constant_rib(&mut self, f: |&mut Resolver|) {
{
let mut value_ribs = self.value_ribs.borrow_mut();
let mut type_ribs = self.type_ribs.borrow_mut();
value_ribs.get().push(@Rib::new(ConstantItemRibKind));
type_ribs.get().push(@Rib::new(ConstantItemRibKind));
}
f(self);
{
let mut value_ribs = self.value_ribs.borrow_mut();
let mut type_ribs = self.type_ribs.borrow_mut();
type_ribs.get().pop();
value_ribs.get().pop();
}
}
2013-10-02 07:33:01 -05:00
fn resolve_function(&mut self,
rib_kind: RibKind,
optional_declaration: Option<P<FnDecl>>,
type_parameters: TypeParameters,
block: P<Block>) {
// Create a value rib for the function.
let function_value_rib = @Rib::new(rib_kind);
{
let mut value_ribs = self.value_ribs.borrow_mut();
value_ribs.get().push(function_value_rib);
}
// Create a label rib for the function.
{
let mut label_ribs = self.label_ribs.borrow_mut();
let function_label_rib = @Rib::new(rib_kind);
label_ribs.get().push(function_label_rib);
}
// If this function has type parameters, add them now.
self.with_type_parameter_rib(type_parameters, |this| {
// Resolve the type parameters.
2012-08-06 14:34:08 -05:00
match type_parameters {
2012-08-03 21:59:04 -05:00
NoTypeParameters => {
// Continue.
}
HasTypeParameters(ref generics, _, _, _) => {
this.resolve_type_parameters(&generics.ty_params);
}
}
// Add each argument to the rib.
2012-08-06 14:34:08 -05:00
match optional_declaration {
2012-08-20 14:23:37 -05:00
None => {
// Nothing to do.
}
2012-08-20 14:23:37 -05:00
Some(declaration) => {
for argument in declaration.inputs.iter() {
let binding_mode = ArgumentIrrefutableMode;
this.resolve_pattern(argument.pat,
binding_mode,
None);
this.resolve_type(argument.ty);
debug!("(resolving function) recorded argument");
}
this.resolve_type(declaration.output);
}
}
// Resolve the function body.
this.resolve_block(block);
debug!("(resolving function) leaving function");
});
let mut label_ribs = self.label_ribs.borrow_mut();
label_ribs.get().pop();
let mut value_ribs = self.value_ribs.borrow_mut();
value_ribs.get().pop();
}
2013-10-02 07:33:01 -05:00
fn resolve_type_parameters(&mut self,
type_parameters: &OptVec<TyParam>) {
for type_parameter in type_parameters.iter() {
for bound in type_parameter.bounds.iter() {
self.resolve_type_parameter_bound(type_parameter.id, bound);
}
match type_parameter.default {
Some(ty) => self.resolve_type(ty),
None => {}
}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_type_parameter_bound(&mut self,
id: NodeId,
type_parameter_bound: &TyParamBound) {
match *type_parameter_bound {
TraitTyParamBound(ref tref) => {
self.resolve_trait_reference(id, tref, TraitBoundingTypeParameter)
}
RegionTyParamBound => {}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_trait_reference(&mut self,
id: NodeId,
trait_reference: &TraitRef,
reference_type: TraitReferenceType) {
match self.resolve_path(id, &trait_reference.path, TypeNS, true) {
None => {
let path_str = self.path_idents_to_str(&trait_reference.path);
let usage_str = match reference_type {
TraitBoundingTypeParameter => "bound type parameter with",
TraitImplementation => "implement",
TraitDerivation => "derive"
};
2013-09-28 00:38:08 -05:00
let msg = format!("attempt to {} a nonexistent trait `{}`", usage_str, path_str);
self.resolve_error(trait_reference.path.span, msg);
}
Some(def) => {
debug!("(resolving trait) found trait def: {:?}", def);
self.record_def(trait_reference.ref_id, def);
}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_struct(&mut self,
id: NodeId,
generics: &Generics,
fields: &[StructField]) {
let mut ident_map: HashMap<ast::Ident, &StructField> = HashMap::new();
for field in fields.iter() {
2013-06-27 19:27:56 -05:00
match field.node.kind {
NamedField(ident, _) => {
2013-06-27 19:27:56 -05:00
match ident_map.find(&ident) {
Some(&prev_field) => {
let ident_str = self.session.str_of(ident);
self.resolve_error(field.span,
2013-09-28 00:38:08 -05:00
format!("field `{}` is already declared", ident_str));
2013-06-27 19:27:56 -05:00
self.session.span_note(prev_field.span,
"previously declared here");
2013-06-27 19:27:56 -05:00
},
None => {
ident_map.insert(ident, field);
}
}
}
_ => ()
}
}
// If applicable, create a rib for the type parameters.
self.with_type_parameter_rib(HasTypeParameters(generics,
id,
0,
OpaqueFunctionRibKind),
|this| {
// Resolve the type parameters.
this.resolve_type_parameters(&generics.ty_params);
// Resolve fields.
for field in fields.iter() {
this.resolve_type(field.node.ty);
}
});
}
// Does this really need to take a RibKind or is it always going
// to be NormalRibKind?
2013-10-02 07:33:01 -05:00
fn resolve_method(&mut self,
rib_kind: RibKind,
method: @Method,
outer_type_parameter_count: uint) {
let method_generics = &method.generics;
let type_parameters =
HasTypeParameters(method_generics,
method.id,
outer_type_parameter_count,
rib_kind);
self.resolve_function(rib_kind, Some(method.decl), type_parameters, method.body);
}
2013-10-02 07:33:01 -05:00
fn resolve_implementation(&mut self,
id: NodeId,
generics: &Generics,
opt_trait_reference: &Option<TraitRef>,
2013-07-05 23:57:11 -05:00
self_type: &Ty,
methods: &[@Method]) {
// If applicable, create a rib for the type parameters.
let outer_type_parameter_count = generics.ty_params.len();
self.with_type_parameter_rib(HasTypeParameters(generics,
id,
0,
NormalRibKind),
|this| {
// Resolve the type parameters.
this.resolve_type_parameters(&generics.ty_params);
// Resolve the trait reference, if necessary.
2013-03-07 17:37:14 -06:00
let original_trait_refs;
match opt_trait_reference {
&Some(ref trait_reference) => {
this.resolve_trait_reference(id, trait_reference,
TraitImplementation);
// Record the current set of trait references.
let mut new_trait_refs = ~[];
{
let def_map = this.def_map.borrow();
let r = def_map.get().find(&trait_reference.ref_id);
for &def in r.iter() {
new_trait_refs.push(def_id_of_def(*def));
}
}
original_trait_refs = Some(replace(
&mut this.current_trait_refs,
Some(new_trait_refs)));
2013-03-07 17:37:14 -06:00
}
&None => {
2013-03-07 17:37:14 -06:00
original_trait_refs = None;
}
}
// Resolve the self type.
this.resolve_type(self_type);
for method in methods.iter() {
// We also need a new scope for the method-specific
// type parameters.
this.resolve_method(MethodRibKind(
id,
Provided(method.id)),
*method,
outer_type_parameter_count);
/*
let borrowed_type_parameters = &method.tps;
self.resolve_function(MethodRibKind(
id,
Provided(method.id)),
Some(method.decl),
HasTypeParameters
(borrowed_type_parameters,
method.id,
outer_type_parameter_count,
NormalRibKind),
method.body);
*/
}
// Restore the original trait references.
2013-03-07 17:37:14 -06:00
match original_trait_refs {
Some(r) => { this.current_trait_refs = r; }
2013-03-07 17:37:14 -06:00
None => ()
}
});
}
fn resolve_module(&mut self, module: &Mod, _span: Span,
_name: Ident, id: NodeId) {
// Write the implementations in scope into the module metadata.
debug!("(resolving module) resolving module ID {}", id);
visit::walk_mod(self, module, ());
}
2014-01-06 06:00:46 -06:00
fn resolve_local(&mut self, local: &Local) {
// Resolve the type.
self.resolve_type(local.ty);
// Resolve the initializer, if necessary.
match local.init {
2012-08-20 14:23:37 -05:00
None => {
// Nothing to do.
}
2012-08-20 14:23:37 -05:00
Some(initializer) => {
self.resolve_expr(initializer);
}
}
// Resolve the pattern.
self.resolve_pattern(local.pat, LocalIrrefutableMode, None);
}
2013-09-05 16:15:00 -05:00
// build a map from pattern identifiers to binding-info's.
// this is done hygienically. This could arise for a macro
// that expands into an or-pattern where one 'x' was from the
// user and one 'x' came from the macro.
2013-10-02 07:33:01 -05:00
fn binding_mode_map(&mut self, pat: @Pat) -> BindingMap {
let mut result = HashMap::new();
pat_bindings(self.def_map, pat, |binding_mode, _id, sp, path| {
2013-09-05 16:15:00 -05:00
let name = mtwt_resolve(path_to_ident(path));
result.insert(name,
binding_info {span: sp,
binding_mode: binding_mode});
});
return result;
}
2013-09-05 16:15:00 -05:00
// check that all of the arms in an or-pattern have exactly the
// same set of bindings, with the same binding modes for each.
2013-10-02 07:33:01 -05:00
fn check_consistent_bindings(&mut self, arm: &Arm) {
if arm.pats.len() == 0 { return; }
let map_0 = self.binding_mode_map(arm.pats[0]);
for (i, p) in arm.pats.iter().enumerate() {
let map_i = self.binding_mode_map(*p);
for (&key, &binding_0) in map_0.iter() {
match map_i.find(&key) {
2012-08-20 14:23:37 -05:00
None => {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(key);
self.resolve_error(
p.span,
2013-09-28 00:38:08 -05:00
format!("variable `{}` from pattern \\#1 is \
not bound in pattern \\#{}",
2014-01-31 14:25:11 -06:00
string.get(),
i + 1));
}
2012-08-20 14:23:37 -05:00
Some(binding_i) => {
if binding_0.binding_mode != binding_i.binding_mode {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(key);
self.resolve_error(
binding_i.span,
2013-09-28 00:38:08 -05:00
format!("variable `{}` is bound with different \
mode in pattern \\#{} than in pattern \\#1",
2014-01-31 14:25:11 -06:00
string.get(),
i + 1));
}
}
}
}
for (&key, &binding) in map_i.iter() {
if !map_0.contains_key(&key) {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(key);
self.resolve_error(
binding.span,
2013-09-28 00:38:08 -05:00
format!("variable `{}` from pattern \\#{} is \
not bound in pattern \\#1",
2014-01-31 14:25:11 -06:00
string.get(),
i + 1));
}
}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_arm(&mut self, arm: &Arm) {
{
let mut value_ribs = self.value_ribs.borrow_mut();
value_ribs.get().push(@Rib::new(NormalRibKind));
}
let mut bindings_list = HashMap::new();
for pattern in arm.pats.iter() {
self.resolve_pattern(*pattern,
RefutableMode,
Some(&mut bindings_list));
}
// This has to happen *after* we determine which
// pat_idents are variants
self.check_consistent_bindings(arm);
visit::walk_expr_opt(self, arm.guard, ());
self.resolve_block(arm.body);
let mut value_ribs = self.value_ribs.borrow_mut();
value_ribs.get().pop();
}
2014-01-06 06:00:46 -06:00
fn resolve_block(&mut self, block: &Block) {
debug!("(resolving block) entering block");
{
let mut value_ribs = self.value_ribs.borrow_mut();
value_ribs.get().push(@Rib::new(NormalRibKind));
}
// Move down in the graph, if there's an anonymous module rooted here.
let orig_module = self.current_module;
let anonymous_children = self.current_module
.anonymous_children
.borrow();
match anonymous_children.get().find(&block.id) {
2012-08-20 14:23:37 -05:00
None => { /* Nothing to do. */ }
2013-03-22 21:26:41 -05:00
Some(&anonymous_module) => {
debug!("(resolving block) found anonymous module, moving \
2012-08-22 19:24:52 -05:00
down");
self.current_module = anonymous_module;
}
}
// Descend into the block.
visit::walk_block(self, block, ());
// Move back up.
self.current_module = orig_module;
let mut value_ribs = self.value_ribs.borrow_mut();
value_ribs.get().pop();
debug!("(resolving block) leaving block");
}
2013-10-02 07:33:01 -05:00
fn resolve_type(&mut self, ty: &Ty) {
2012-08-06 14:34:08 -05:00
match ty.node {
// Like path expressions, the interpretation of path types depends
// on whether the path has multiple elements in it or not.
TyPath(ref path, ref bounds, path_id) => {
// This is a path in the type namespace. Walk through scopes
// scopes looking for it.
let mut result_def = None;
// First, check to see whether the name is a primitive type.
if path.segments.len() == 1 {
let id = path.segments.last().unwrap().identifier;
match self.primitive_type_table
.primitive_types
.find(&id.name) {
2013-03-22 21:26:41 -05:00
Some(&primitive_type) => {
result_def =
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
Some((DefPrimTy(primitive_type), AllPublic));
if path.segments
.iter()
.any(|s| !s.lifetimes.is_empty()) {
self.session.span_err(path.span,
"lifetime parameters \
are not allowed on \
this type")
} else if path.segments
.iter()
.any(|s| s.types.len() > 0) {
self.session.span_err(path.span,
"type parameters are \
not allowed on this \
type")
}
}
None => {
// Continue.
}
}
}
2012-08-06 14:34:08 -05:00
match result_def {
2012-08-20 14:23:37 -05:00
None => {
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
match self.resolve_path(ty.id, path, TypeNS, true) {
Some(def) => {
debug!("(resolving type) resolved `{}` to \
2013-09-28 00:38:08 -05:00
type {:?}",
self.session.str_of(path.segments
.last().unwrap()
.identifier),
def);
result_def = Some(def);
}
None => {
result_def = None;
}
}
}
Some(_) => {} // Continue.
}
match result_def {
2012-08-20 14:23:37 -05:00
Some(def) => {
// Write the result into the def map.
debug!("(resolving type) writing resolution for `{}` \
2013-09-28 00:38:08 -05:00
(id {})",
self.path_idents_to_str(path),
2012-08-22 19:24:52 -05:00
path_id);
self.record_def(path_id, def);
}
2012-08-20 14:23:37 -05:00
None => {
2013-09-28 00:38:08 -05:00
let msg = format!("use of undeclared type name `{}`",
self.path_idents_to_str(path));
self.resolve_error(ty.span, msg);
}
}
bounds.as_ref().map(|bound_vec| {
for bound in bound_vec.iter() {
self.resolve_type_parameter_bound(ty.id, bound);
}
});
}
TyClosure(c) => {
c.bounds.as_ref().map(|bounds| {
for bound in bounds.iter() {
self.resolve_type_parameter_bound(ty.id, bound);
}
});
visit::walk_ty(self, ty, ());
}
2012-08-03 21:59:04 -05:00
_ => {
// Just resolve embedded types.
visit::walk_ty(self, ty, ());
}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_pattern(&mut self,
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
pattern: @Pat,
mode: PatternBindingMode,
// Maps idents to the node ID for the (outermost)
// pattern that binds them
mut bindings_list: Option<&mut HashMap<Name,NodeId>>) {
let pat_id = pattern.id;
walk_pat(pattern, |pattern| {
2012-08-06 14:34:08 -05:00
match pattern.node {
PatIdent(binding_mode, ref path, _)
if !path.global && path.segments.len() == 1 => {
// The meaning of pat_ident with no type parameters
// depends on whether an enum variant or unit-like struct
// with that name is in scope. The probing lookup has to
// be careful not to emit spurious errors. Only matching
// patterns (match) can match nullary variants or
// unit-like structs. For binding patterns (let), matching
// such a value is simply disallowed (since it's rarely
// what you want).
let ident = path.segments[0].identifier;
2013-09-05 16:15:00 -05:00
let renamed = mtwt_resolve(ident);
match self.resolve_bare_identifier_pattern(ident) {
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
FoundStructOrEnumVariant(def, lp)
if mode == RefutableMode => {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(renamed);
debug!("(resolving pattern) resolving `{}` to \
struct or enum variant",
2014-01-31 14:25:11 -06:00
string.get());
self.enforce_default_binding_mode(
pattern,
binding_mode,
"an enum variant");
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
self.record_def(pattern.id, (def, lp));
}
2013-11-28 14:22:53 -06:00
FoundStructOrEnumVariant(..) => {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(renamed);
self.resolve_error(pattern.span,
2013-09-28 00:38:08 -05:00
format!("declaration of `{}` \
shadows an enum \
variant or unit-like \
struct in scope",
2014-01-31 14:25:11 -06:00
string.get()));
}
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
FoundConst(def, lp) if mode == RefutableMode => {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(renamed);
debug!("(resolving pattern) resolving `{}` to \
constant",
2014-01-31 14:25:11 -06:00
string.get());
self.enforce_default_binding_mode(
pattern,
binding_mode,
"a constant");
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
self.record_def(pattern.id, (def, lp));
}
2013-11-28 14:22:53 -06:00
FoundConst(..) => {
self.resolve_error(pattern.span,
2013-10-02 07:33:01 -05:00
"only irrefutable patterns \
allowed here");
}
BareIdentifierPatternUnresolved => {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(renamed);
debug!("(resolving pattern) binding `{}`",
2014-01-31 14:25:11 -06:00
string.get());
2012-08-06 14:34:08 -05:00
let def = match mode {
2012-08-03 21:59:04 -05:00
RefutableMode => {
// For pattern arms, we must use
// `def_binding` definitions.
DefBinding(pattern.id, binding_mode)
}
LocalIrrefutableMode => {
// But for locals, we use `def_local`.
DefLocal(pattern.id, binding_mode)
}
ArgumentIrrefutableMode => {
// And for function arguments, `def_arg`.
DefArg(pattern.id, binding_mode)
}
};
// Record the definition so that later passes
// will be able to distinguish variants from
// locals in patterns.
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
self.record_def(pattern.id, (def, AllPublic));
// Add the binding to the local ribs, if it
// doesn't already exist in the bindings list. (We
// must not add it if it's in the bindings list
// because that breaks the assumptions later
// passes make about or-patterns.)
2012-08-06 14:34:08 -05:00
match bindings_list {
Some(ref mut bindings_list)
if !bindings_list.contains_key(&renamed) => {
let this = &mut *self;
2013-12-21 15:58:11 -06:00
{
let mut value_ribs =
this.value_ribs.borrow_mut();
let last_rib = value_ribs.get()[
value_ribs.get().len() - 1];
2013-12-21 15:58:11 -06:00
let mut bindings =
last_rib.bindings.borrow_mut();
bindings.get().insert(renamed,
DlDef(def));
}
bindings_list.insert(renamed, pat_id);
}
Some(ref mut b) => {
if b.find(&renamed) == Some(&pat_id) {
// Then this is a duplicate variable
// in the same disjunct, which is an
// error
self.resolve_error(pattern.span,
format!("identifier `{}` is bound more \
than once in the same pattern",
2012-07-18 18:18:02 -05:00
path_to_str(path, self.session
2012-08-22 19:24:52 -05:00
.intr())));
}
// Not bound in the same pattern: do nothing
}
2012-08-20 14:23:37 -05:00
None => {
let this = &mut *self;
2013-12-21 15:58:11 -06:00
{
let mut value_ribs =
this.value_ribs.borrow_mut();
let last_rib = value_ribs.get()[
value_ribs.get().len() - 1];
2013-12-21 15:58:11 -06:00
let mut bindings =
last_rib.bindings.borrow_mut();
bindings.get().insert(renamed,
DlDef(def));
}
}
}
}
}
// Check the types in the path pattern.
for &ty in path.segments
.iter()
.flat_map(|seg| seg.types.iter()) {
self.resolve_type(ty);
}
}
PatIdent(binding_mode, ref path, _) => {
// This must be an enum variant, struct, or constant.
match self.resolve_path(pat_id, path, ValueNS, false) {
2013-11-28 14:22:53 -06:00
Some(def @ (DefVariant(..), _)) |
Some(def @ (DefStruct(..), _)) => {
self.record_def(pattern.id, def);
}
2013-11-28 14:22:53 -06:00
Some(def @ (DefStatic(..), _)) => {
self.enforce_default_binding_mode(
pattern,
binding_mode,
"a constant");
self.record_def(pattern.id, def);
}
2012-08-20 14:23:37 -05:00
Some(_) => {
self.resolve_error(
2012-07-18 18:18:02 -05:00
path.span,
2013-09-28 00:38:08 -05:00
format!("`{}` is not an enum variant or constant",
self.session.str_of(
path.segments.last().unwrap().identifier)))
}
2012-08-20 14:23:37 -05:00
None => {
self.resolve_error(path.span,
"unresolved enum variant");
}
}
// Check the types in the path pattern.
for &ty in path.segments
.iter()
.flat_map(|s| s.types.iter()) {
self.resolve_type(ty);
}
}
PatEnum(ref path, _) => {
// This must be an enum variant, struct or const.
match self.resolve_path(pat_id, path, ValueNS, false) {
2013-11-28 14:22:53 -06:00
Some(def @ (DefFn(..), _)) |
Some(def @ (DefVariant(..), _)) |
Some(def @ (DefStruct(..), _)) |
Some(def @ (DefStatic(..), _)) => {
self.record_def(pattern.id, def);
}
Some(_) => {
self.resolve_error(
path.span,
2013-09-28 00:38:08 -05:00
format!("`{}` is not an enum variant, struct or const",
self.session
.str_of(path.segments
.last().unwrap()
.identifier)));
}
None => {
self.resolve_error(path.span,
2013-09-28 00:38:08 -05:00
format!("unresolved enum variant, \
struct or const `{}`",
self.session
.str_of(path.segments
.last().unwrap()
.identifier)));
}
}
// Check the types in the path pattern.
for &ty in path.segments
.iter()
.flat_map(|s| s.types.iter()) {
self.resolve_type(ty);
}
}
PatLit(expr) => {
self.resolve_expr(expr);
}
PatRange(first_expr, last_expr) => {
self.resolve_expr(first_expr);
self.resolve_expr(last_expr);
}
PatStruct(ref path, _, _) => {
match self.resolve_path(pat_id, path, TypeNS, false) {
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
Some((DefTy(class_id), lp))
2013-05-02 13:32:37 -05:00
if self.structs.contains(&class_id) => {
let class_def = DefStruct(class_id);
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
self.record_def(pattern.id, (class_def, lp));
}
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
Some(definition @ (DefStruct(class_id), _)) => {
2013-05-02 13:32:37 -05:00
assert!(self.structs.contains(&class_id));
self.record_def(pattern.id, definition);
}
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
Some(definition @ (DefVariant(_, variant_id, _), _))
2013-05-02 13:32:37 -05:00
if self.structs.contains(&variant_id) => {
self.record_def(pattern.id, definition);
}
result => {
debug!("(resolving pattern) didn't find struct \
2013-09-28 00:38:08 -05:00
def: {:?}", result);
let msg = format!("`{}` does not name a structure",
self.path_idents_to_str(path));
self.resolve_error(path.span, msg);
}
}
}
_ => {
// Nothing to do.
}
}
true
});
}
2013-10-02 07:33:01 -05:00
fn resolve_bare_identifier_pattern(&mut self, name: Ident)
->
BareIdentifierPatternResolution {
2012-08-06 14:34:08 -05:00
match self.resolve_item_in_lexical_scope(self.current_module,
name,
ValueNS,
SearchThroughModules) {
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
Success((target, _)) => {
debug!("(resolve bare identifier pattern) succeeded in \
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
finding {} at {:?}",
self.session.str_of(name),
target.bindings.value_def.get());
match target.bindings.value_def.get() {
2012-08-20 14:23:37 -05:00
None => {
fail!("resolved name in the value namespace to a \
set of name bindings with no def?!");
}
2012-08-20 14:23:37 -05:00
Some(def) => {
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
// For the two success cases, this lookup can be
// considered as not having a private component because
// the lookup happened only within the current module.
match def.def {
2013-11-28 14:22:53 -06:00
def @ DefVariant(..) | def @ DefStruct(..) => {
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
return FoundStructOrEnumVariant(def, AllPublic);
}
def @ DefStatic(_, false) => {
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
return FoundConst(def, AllPublic);
}
_ => {
return BareIdentifierPatternUnresolved;
}
}
}
}
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
fail!("unexpected indeterminate result");
}
2012-08-03 21:59:04 -05:00
Failed => {
debug!("(resolve bare identifier pattern) failed to find {}",
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
self.session.str_of(name));
return BareIdentifierPatternUnresolved;
}
}
}
/// If `check_ribs` is true, checks the local definitions first; i.e.
/// doesn't skip straight to the containing module.
2013-10-02 07:33:01 -05:00
fn resolve_path(&mut self,
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
id: NodeId,
path: &Path,
namespace: Namespace,
check_ribs: bool) -> Option<(Def, LastPrivate)> {
// First, resolve the types.
for &ty in path.segments.iter().flat_map(|s| s.types.iter()) {
self.resolve_type(ty);
}
if path.global {
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
return self.resolve_crate_relative_path(path, namespace);
}
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
let unqualified_def =
self.resolve_identifier(path.segments
.last().unwrap()
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
.identifier,
namespace,
check_ribs,
path.span);
if path.segments.len() > 1 {
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
let def = self.resolve_module_relative_path(path, namespace);
match (def, unqualified_def) {
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
(Some((d, _)), Some((ud, _))) if d == ud => {
2014-01-09 20:29:45 -06:00
self.session.add_lint(UnnecessaryQualification,
id,
path.span,
~"unnecessary qualification");
}
_ => ()
}
return def;
}
return unqualified_def;
}
2013-05-30 19:46:25 -05:00
// resolve a single identifier (used as a varref)
2013-10-02 07:33:01 -05:00
fn resolve_identifier(&mut self,
2013-09-01 19:50:59 -05:00
identifier: Ident,
namespace: Namespace,
check_ribs: bool,
span: Span)
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
-> Option<(Def, LastPrivate)> {
if check_ribs {
2012-08-06 14:34:08 -05:00
match self.resolve_identifier_in_local_ribs(identifier,
namespace,
span) {
2012-08-20 14:23:37 -05:00
Some(def) => {
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
return Some((def, AllPublic));
}
2012-08-20 14:23:37 -05:00
None => {
// Continue.
}
}
}
2012-08-01 19:30:05 -05:00
return self.resolve_item_by_identifier_in_lexical_scope(identifier,
namespace);
}
// FIXME #4952: Merge me with resolve_name_in_module?
2013-10-02 07:33:01 -05:00
fn resolve_definition_of_name_in_module(&mut self,
2013-12-19 21:02:22 -06:00
containing_module: @Module,
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
name: Ident,
namespace: Namespace)
-> NameDefinition {
// First, search children.
self.populate_module_if_necessary(containing_module);
2013-12-21 17:32:44 -06:00
{
let children = containing_module.children.borrow();
match children.get().find(&name.name) {
Some(child_name_bindings) => {
match child_name_bindings.def_for_namespace(namespace) {
Some(def) => {
// Found it. Stop the search here.
let p = child_name_bindings.defined_in_public_namespace(
namespace);
let lp = if p {AllPublic} else {
DependsOn(def_id_of_def(def))
};
return ChildNameDefinition(def, lp);
}
None => {}
}
}
2013-12-21 17:32:44 -06:00
None => {}
}
}
// Next, search import resolutions.
let import_resolutions = containing_module.import_resolutions
.borrow();
match import_resolutions.get().find(&name.name) {
Some(import_resolution) if import_resolution.is_public.get() => {
2012-08-06 14:34:08 -05:00
match (*import_resolution).target_for_namespace(namespace) {
2012-08-20 14:23:37 -05:00
Some(target) => {
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
match target.bindings.def_for_namespace(namespace) {
Some(def) => {
// Found it.
let id = import_resolution.id(namespace);
self.used_imports.insert(id);
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
return ImportNameDefinition(def, AllPublic);
}
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
None => {
// This can happen with external impls, due to
// the imperfect way we read the metadata.
}
}
}
None => {}
}
}
2013-11-28 14:22:53 -06:00
Some(..) | None => {} // Continue.
}
// Finally, search through external children.
if namespace == TypeNS {
let module_opt = {
let external_module_children =
containing_module.external_module_children.borrow();
external_module_children.get().find_copy(&name.name)
};
match module_opt {
None => {}
Some(module) => {
match module.def_id.get() {
None => {} // Continue.
Some(def_id) => {
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
let lp = if module.is_public {AllPublic} else {
DependsOn(def_id)
};
return ChildNameDefinition(DefMod(def_id), lp);
}
}
}
}
}
return NoNameDefinition;
}
// resolve a "module-relative" path, e.g. a::b::c
2013-10-02 07:33:01 -05:00
fn resolve_module_relative_path(&mut self,
2013-07-05 05:15:21 -05:00
path: &Path,
namespace: Namespace)
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
-> Option<(Def, LastPrivate)> {
let module_path_idents = path.segments.init().map(|ps| ps.identifier);
2013-04-12 00:15:30 -05:00
let containing_module;
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
let last_private;
match self.resolve_module_path(self.current_module,
module_path_idents,
UseLexicalScope,
path.span,
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
PathSearch) {
2012-08-03 21:59:04 -05:00
Failed => {
2013-09-28 00:38:08 -05:00
let msg = format!("use of undeclared module `{}`",
self.idents_to_str(module_path_idents));
self.resolve_error(path.span, msg);
2012-08-20 14:23:37 -05:00
return None;
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
fail!("indeterminate unexpected");
}
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
Success((resulting_module, resulting_last_private)) => {
containing_module = resulting_module;
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
last_private = resulting_last_private;
}
}
let ident = path.segments.last().unwrap().identifier;
let def = match self.resolve_definition_of_name_in_module(containing_module,
ident,
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
namespace) {
2012-08-03 21:59:04 -05:00
NoNameDefinition => {
// We failed to resolve the name. Report an error.
2012-08-20 14:23:37 -05:00
return None;
}
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
ChildNameDefinition(def, lp) | ImportNameDefinition(def, lp) => {
(def, last_private.or(lp))
}
};
match containing_module.kind.get() {
TraitModuleKind | ImplModuleKind => {
2013-12-21 19:04:42 -06:00
let method_map = self.method_map.borrow();
match method_map.get().find(&ident.name) {
Some(s) => {
match containing_module.def_id.get() {
Some(def_id) if s.contains(&def_id) => {
debug!("containing module was a trait or impl \
and name was a method -> not resolved");
return None;
},
_ => (),
}
},
None => (),
}
},
_ => (),
};
return Some(def);
}
/// Invariant: This must be called only during main resolution, not during
/// import resolution.
2013-10-02 07:33:01 -05:00
fn resolve_crate_relative_path(&mut self,
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
path: &Path,
namespace: Namespace)
-> Option<(Def, LastPrivate)> {
let module_path_idents = path.segments.init().map(|ps| ps.identifier);
let root_module = self.graph_root.get_module();
2013-04-12 00:15:30 -05:00
let containing_module;
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
let last_private;
2012-08-06 14:34:08 -05:00
match self.resolve_module_path_from_root(root_module,
module_path_idents,
0,
path.span,
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
PathSearch,
AllPublic) {
2012-08-03 21:59:04 -05:00
Failed => {
2013-09-28 00:38:08 -05:00
let msg = format!("use of undeclared module `::{}`",
self.idents_to_str(module_path_idents));
self.resolve_error(path.span, msg);
2012-08-20 14:23:37 -05:00
return None;
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
fail!("indeterminate unexpected");
}
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
Success((resulting_module, resulting_last_private)) => {
containing_module = resulting_module;
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
last_private = resulting_last_private;
}
}
let name = path.segments.last().unwrap().identifier;
2012-08-06 14:34:08 -05:00
match self.resolve_definition_of_name_in_module(containing_module,
name,
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
namespace) {
2012-08-03 21:59:04 -05:00
NoNameDefinition => {
// We failed to resolve the name. Report an error.
2012-08-20 14:23:37 -05:00
return None;
}
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
ChildNameDefinition(def, lp) | ImportNameDefinition(def, lp) => {
return Some((def, last_private.or(lp)));
}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_identifier_in_local_ribs(&mut self,
2013-09-01 19:50:59 -05:00
ident: Ident,
namespace: Namespace,
span: Span)
-> Option<Def> {
// Check the local set of ribs.
2013-04-12 00:15:30 -05:00
let search_result;
2012-08-06 14:34:08 -05:00
match namespace {
2012-08-03 21:59:04 -05:00
ValueNS => {
2013-09-05 16:15:00 -05:00
let renamed = mtwt_resolve(ident);
let mut value_ribs = self.value_ribs.borrow_mut();
search_result = self.search_ribs(value_ribs.get(),
renamed,
span);
}
2012-08-03 21:59:04 -05:00
TypeNS => {
let name = ident.name;
let mut type_ribs = self.type_ribs.borrow_mut();
search_result = self.search_ribs(type_ribs.get(),
name,
span);
}
}
match search_result {
Some(DlDef(def)) => {
debug!("(resolving path in local ribs) resolved `{}` to \
2013-09-28 00:38:08 -05:00
local: {:?}",
self.session.str_of(ident),
2012-08-22 19:24:52 -05:00
def);
2012-08-20 14:23:37 -05:00
return Some(def);
}
Some(DlField) | Some(DlImpl(_)) | None => {
2012-08-20 14:23:37 -05:00
return None;
}
}
}
2013-10-02 07:33:01 -05:00
fn resolve_item_by_identifier_in_lexical_scope(&mut self,
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
ident: Ident,
namespace: Namespace)
-> Option<(Def, LastPrivate)> {
// Check the items.
2012-08-06 14:34:08 -05:00
match self.resolve_item_in_lexical_scope(self.current_module,
ident,
namespace,
DontSearchThroughModules) {
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
Success((target, _)) => {
2012-08-06 14:34:08 -05:00
match (*target.bindings).def_for_namespace(namespace) {
2012-08-20 14:23:37 -05:00
None => {
// This can happen if we were looking for a type and
// found a module instead. Modules don't have defs.
debug!("(resolving item path by identifier in lexical \
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
scope) failed to resolve {} after success...",
self.session.str_of(ident));
return None;
}
2012-08-20 14:23:37 -05:00
Some(def) => {
debug!("(resolving item path in lexical scope) \
2013-09-28 00:38:08 -05:00
resolved `{}` to item",
self.session.str_of(ident));
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
// This lookup is "all public" because it only searched
// for one identifier in the current module (couldn't
// have passed through reexports or anything like that.
return Some((def, AllPublic));
}
}
}
2012-08-03 21:59:04 -05:00
Indeterminate => {
fail!("unexpected indeterminate result");
}
2012-08-03 21:59:04 -05:00
Failed => {
debug!("(resolving item path by identifier in lexical scope) \
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
failed to resolve {}", self.session.str_of(ident));
2012-08-20 14:23:37 -05:00
return None;
}
}
}
fn with_no_errors<T>(&mut self, f: |&mut Resolver| -> T) -> T {
self.emit_errors = false;
let rs = f(self);
self.emit_errors = true;
rs
}
fn resolve_error(&mut self, span: Span, s: &str) {
if self.emit_errors {
self.session.span_err(span, s);
}
}
fn find_best_match_for_name(&mut self, name: &str, max_distance: uint)
2014-01-31 14:25:11 -06:00
-> Option<~str> {
let this = &mut *self;
2014-01-31 14:25:11 -06:00
let mut maybes: ~[~str] = ~[];
let mut values: ~[uint] = ~[];
let mut j = {
let value_ribs = this.value_ribs.borrow();
value_ribs.get().len()
};
while j != 0 {
j -= 1;
let value_ribs = this.value_ribs.borrow();
let bindings = value_ribs.get()[j].bindings.borrow();
2013-12-21 15:58:11 -06:00
for (&k, _) in bindings.get().iter() {
2014-01-31 14:25:11 -06:00
let string = token::get_ident(k);
maybes.push(string.get().to_str());
values.push(uint::MAX);
}
}
let mut smallest = 0;
2014-01-31 14:25:11 -06:00
for (i, other) in maybes.iter().enumerate() {
values[i] = name.lev_distance(*other);
if values[i] <= values[smallest] {
smallest = i;
}
}
2013-05-14 04:52:12 -05:00
if values.len() > 0 &&
values[smallest] != uint::MAX &&
values[smallest] < name.len() + 2 &&
values[smallest] <= max_distance &&
name != maybes[smallest] {
Some(maybes.swap_remove(smallest))
} else {
None
}
}
2014-01-06 06:00:46 -06:00
fn resolve_expr(&mut self, expr: &Expr) {
2012-08-17 18:53:07 -05:00
// First, record candidate traits for this expression if it could
// result in the invocation of a method call.
self.record_candidate_traits_for_expr_if_necessary(expr);
// Next, resolve the node.
2012-08-06 14:34:08 -05:00
match expr.node {
// The interpretation of paths depends on whether the path has
// multiple elements in it or not.
ExprPath(ref path) => {
// This is a local path in the value namespace. Walk through
// scopes looking for it.
match self.resolve_path(expr.id, path, ValueNS, true) {
2012-08-20 14:23:37 -05:00
Some(def) => {
// Write the result into the def map.
debug!("(resolving expr) resolved `{}`",
self.path_idents_to_str(path));
// First-class methods are not supported yet; error
// out here.
match def {
2013-11-28 14:22:53 -06:00
(DefMethod(..), _) => {
self.resolve_error(expr.span,
"first-class methods \
are not supported");
self.session.span_note(expr.span,
"call the method \
using the `.` \
syntax");
}
_ => {}
}
self.record_def(expr.id, def);
}
2012-08-20 14:23:37 -05:00
None => {
let wrong_name = self.path_idents_to_str(path);
2013-09-27 21:46:09 -05:00
// Be helpful if the name refers to a struct
// (The pattern matching def_tys where the id is in self.structs
// matches on regular structs while excluding tuple- and enum-like
// structs, which wouldn't result in this error.)
match self.with_no_errors(|this|
this.resolve_path(expr.id, path, TypeNS, false)) {
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
Some((DefTy(struct_id), _))
2013-09-27 21:46:09 -05:00
if self.structs.contains(&struct_id) => {
self.resolve_error(expr.span,
2013-09-28 00:38:08 -05:00
format!("`{}` is a structure name, but \
this expression \
uses it like a function name",
wrong_name));
2013-09-27 21:46:09 -05:00
2013-09-28 00:38:08 -05:00
self.session.span_note(expr.span,
format!("Did you mean to write: \
`{} \\{ /* fields */ \\}`?",
wrong_name));
}
2013-09-27 21:46:09 -05:00
_ =>
// limit search to 5 to reduce the number
// of stupid suggestions
match self.find_best_match_for_name(wrong_name, 5) {
Some(m) => {
self.resolve_error(expr.span,
2013-09-28 00:38:08 -05:00
format!("unresolved name `{}`. \
Did you mean `{}`?",
wrong_name, m));
2013-09-27 21:46:09 -05:00
}
None => {
self.resolve_error(expr.span,
2013-09-28 00:38:08 -05:00
format!("unresolved name `{}`.",
wrong_name));
2013-09-27 21:46:09 -05:00
}
}
2012-08-22 13:40:42 -05:00
}
}
}
visit::walk_expr(self, expr, ());
}
ExprFnBlock(fn_decl, block) |
ExprProc(fn_decl, block) => {
self.resolve_function(FunctionRibKind(expr.id, block.id),
Some(fn_decl), NoTypeParameters,
block);
}
ExprStruct(ref path, _, _) => {
// Resolve the path to the structure it goes to.
match self.resolve_path(expr.id, path, TypeNS, false) {
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
Some((DefTy(class_id), lp)) | Some((DefStruct(class_id), lp))
2013-05-02 13:32:37 -05:00
if self.structs.contains(&class_id) => {
let class_def = DefStruct(class_id);
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
self.record_def(expr.id, (class_def, lp));
}
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
Some(definition @ (DefVariant(_, class_id, _), _))
2013-05-02 13:32:37 -05:00
if self.structs.contains(&class_id) => {
self.record_def(expr.id, definition);
}
result => {
debug!("(resolving expression) didn't find struct \
2013-09-28 00:38:08 -05:00
def: {:?}", result);
let msg = format!("`{}` does not name a structure",
self.path_idents_to_str(path));
self.resolve_error(path.span, msg);
}
}
visit::walk_expr(self, expr, ());
}
ExprLoop(_, Some(label)) => {
self.with_label_rib(|this| {
let def_like = DlDef(DefLabel(expr.id));
// plain insert (no renaming)
2013-12-21 15:58:11 -06:00
{
let mut label_ribs = this.label_ribs.borrow_mut();
let rib = label_ribs.get()[label_ribs.get().len() -
1];
2013-12-21 15:58:11 -06:00
let mut bindings = rib.bindings.borrow_mut();
bindings.get().insert(label.name, def_like);
}
visit::walk_expr(this, expr, ());
})
}
2013-11-28 14:22:53 -06:00
ExprForLoop(..) => fail!("non-desugared expr_for_loop"),
ExprBreak(Some(label)) | ExprAgain(Some(label)) => {
let mut label_ribs = self.label_ribs.borrow_mut();
match self.search_ribs(label_ribs.get(), label, expr.span) {
2012-08-20 14:23:37 -05:00
None =>
self.resolve_error(expr.span,
2013-09-28 00:38:08 -05:00
format!("use of undeclared label \
`{}`",
2014-01-31 14:25:11 -06:00
token::get_ident(label)
.get()
.to_str())),
Some(DlDef(def @ DefLabel(_))) => {
// FIXME: is AllPublic correct?
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
self.record_def(expr.id, (def, AllPublic))
}
Some(_) => {
self.session.span_bug(expr.span,
"label wasn't mapped to a \
label def!")
}
}
}
2012-08-03 21:59:04 -05:00
_ => {
visit::walk_expr(self, expr, ());
}
}
}
2014-01-06 06:00:46 -06:00
fn record_candidate_traits_for_expr_if_necessary(&mut self, expr: &Expr) {
2012-08-06 14:34:08 -05:00
match expr.node {
ExprField(_, ident, _) => {
// FIXME(#6890): Even though you can't treat a method like a
// field, we need to add any trait methods we find that match
// the field name so that we can do some nice error reporting
// later on in typeck.
2012-07-18 18:18:02 -05:00
let traits = self.search_for_traits_containing_method(ident);
2013-12-22 16:03:39 -06:00
self.trait_map.insert(expr.id, @RefCell::new(traits));
}
ExprMethodCall(_, ident, _, _, _) => {
debug!("(recording candidate traits for expr) recording \
2013-09-28 00:38:08 -05:00
traits for {}",
expr.id);
let traits = self.search_for_traits_containing_method(ident);
2013-12-22 16:03:39 -06:00
self.trait_map.insert(expr.id, @RefCell::new(traits));
}
ExprBinary(_, BiAdd, _, _) | ExprAssignOp(_, BiAdd, _, _) => {
let i = self.lang_items.add_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiSub, _, _) | ExprAssignOp(_, BiSub, _, _) => {
let i = self.lang_items.sub_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiMul, _, _) | ExprAssignOp(_, BiMul, _, _) => {
let i = self.lang_items.mul_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiDiv, _, _) | ExprAssignOp(_, BiDiv, _, _) => {
let i = self.lang_items.div_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiRem, _, _) | ExprAssignOp(_, BiRem, _, _) => {
let i = self.lang_items.rem_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiBitXor, _, _) | ExprAssignOp(_, BiBitXor, _, _) => {
let i = self.lang_items.bitxor_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiBitAnd, _, _) | ExprAssignOp(_, BiBitAnd, _, _) => {
let i = self.lang_items.bitand_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiBitOr, _, _) | ExprAssignOp(_, BiBitOr, _, _) => {
let i = self.lang_items.bitor_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiShl, _, _) | ExprAssignOp(_, BiShl, _, _) => {
let i = self.lang_items.shl_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiShr, _, _) | ExprAssignOp(_, BiShr, _, _) => {
let i = self.lang_items.shr_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprBinary(_, BiLt, _, _) | ExprBinary(_, BiLe, _, _) |
ExprBinary(_, BiGe, _, _) | ExprBinary(_, BiGt, _, _) => {
let i = self.lang_items.ord_trait();
self.add_fixed_trait_for_expr(expr.id, i);
2012-08-27 18:26:35 -05:00
}
ExprBinary(_, BiEq, _, _) | ExprBinary(_, BiNe, _, _) => {
let i = self.lang_items.eq_trait();
self.add_fixed_trait_for_expr(expr.id, i);
2012-08-27 18:26:35 -05:00
}
ExprUnary(_, UnNeg, _) => {
let i = self.lang_items.neg_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
ExprUnary(_, UnNot, _) => {
let i = self.lang_items.not_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
2013-11-28 14:22:53 -06:00
ExprIndex(..) => {
let i = self.lang_items.index_trait();
self.add_fixed_trait_for_expr(expr.id, i);
}
_ => {
// Nothing to do.
}
}
}
fn search_for_traits_containing_method(&mut self, name: Ident) -> ~[DefId] {
debug!("(searching for traits containing method) looking for '{}'",
self.session.str_of(name));
2013-03-07 17:37:14 -06:00
let mut found_traits = ~[];
let mut search_module = self.current_module;
2013-12-21 19:04:42 -06:00
let method_map = self.method_map.borrow();
match method_map.get().find(&name.name) {
Some(candidate_traits) => loop {
// Look for the current trait.
2013-07-02 14:47:32 -05:00
match self.current_trait_refs {
Some(ref trait_def_ids) => {
for trait_def_id in trait_def_ids.iter() {
if candidate_traits.contains(trait_def_id) {
2013-07-02 14:47:32 -05:00
self.add_trait_info(&mut found_traits,
*trait_def_id,
name);
}
}
}
2012-08-20 14:23:37 -05:00
None => {
// Nothing to do.
}
}
// Look for trait children.
self.populate_module_if_necessary(search_module);
2013-12-21 17:32:44 -06:00
let children = search_module.children.borrow();
for (_, &child_names) in children.get().iter() {
let def = match child_names.def_for_namespace(TypeNS) {
Some(def) => def,
None => continue
};
let trait_def_id = match def {
DefTrait(trait_def_id) => trait_def_id,
_ => continue,
};
if candidate_traits.contains(&trait_def_id) {
self.add_trait_info(&mut found_traits, trait_def_id,
name);
}
}
// Look for imports.
let import_resolutions = search_module.import_resolutions
.borrow();
for (_, &import) in import_resolutions.get().iter() {
let target = match import.target_for_namespace(TypeNS) {
None => continue,
Some(target) => target,
};
let did = match target.bindings.def_for_namespace(TypeNS) {
Some(DefTrait(trait_def_id)) => trait_def_id,
Some(..) | None => continue,
};
if candidate_traits.contains(&did) {
self.add_trait_info(&mut found_traits, did, name);
self.used_imports.insert(import.type_id.get());
}
}
match search_module.parent_link {
NoParentLink | ModuleParentLink(..) => break,
BlockParentLink(parent_module, _) => {
search_module = parent_module;
}
}
},
_ => ()
}
2012-08-01 19:30:05 -05:00
return found_traits;
}
2013-10-02 07:33:01 -05:00
fn add_trait_info(&self,
found_traits: &mut ~[DefId],
trait_def_id: DefId,
2013-09-01 19:50:59 -05:00
name: Ident) {
debug!("(adding trait info) found trait {}:{} for method '{}'",
trait_def_id.crate,
trait_def_id.node,
self.session.str_of(name));
found_traits.push(trait_def_id);
}
2013-10-02 07:33:01 -05:00
fn add_fixed_trait_for_expr(&mut self,
expr_id: NodeId,
trait_id: Option<DefId>) {
match trait_id {
Some(trait_id) => {
2013-12-22 16:03:39 -06:00
self.trait_map.insert(expr_id, @RefCell::new(~[trait_id]));
}
None => {}
}
}
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
fn record_def(&mut self, node_id: NodeId, (def, lp): (Def, LastPrivate)) {
debug!("(recording def) recording {:?} for {:?}, last 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
def, node_id, lp);
self.last_private.insert(node_id, lp);
let mut def_map = self.def_map.borrow_mut();
def_map.get().insert_or_update_with(node_id, def, |_, old_value| {
// Resolve appears to "resolve" the same ID multiple
// times, so here is a sanity check it at least comes to
// the same conclusion! - nmatsakis
if def != *old_value {
2013-09-28 00:38:08 -05:00
self.session.bug(format!("node_id {:?} resolved first to {:?} \
and then {:?}", node_id, *old_value, def));
}
});
}
2013-10-02 07:33:01 -05:00
fn enforce_default_binding_mode(&mut self,
pat: &Pat,
pat_binding_mode: BindingMode,
descr: &str) {
match pat_binding_mode {
BindByValue(_) => {}
2013-11-28 14:22:53 -06:00
BindByRef(..) => {
self.resolve_error(
pat.span,
2013-09-28 00:38:08 -05:00
format!("cannot use `ref` binding mode with {}",
descr));
}
}
}
//
// Unused import checking
//
// Although this is a lint pass, it lives in here because it depends on
// resolve data structures.
//
2013-10-02 07:33:01 -05:00
fn check_for_unused_imports(&self, crate: &ast::Crate) {
let mut visitor = UnusedImportCheckVisitor{ resolver: self };
2013-09-27 21:46:09 -05:00
visit::walk_crate(&mut visitor, crate, ());
}
fn check_for_item_unused_imports(&self, vi: &ViewItem) {
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
// Ignore is_public import statements because there's no way to be sure
// whether they're used or not. Also ignore imports with a dummy span
// because this means that they were generated in some fashion by the
// compiler and we don't need to consider them.
if vi.vis == Public { return }
if vi.span == DUMMY_SP { return }
match vi.node {
ViewItemExternMod(..) => {} // ignore
ViewItemUse(ref path) => {
for p in path.iter() {
match p.node {
ViewPathSimple(_, _, id) | ViewPathGlob(_, id) => {
if !self.used_imports.contains(&id) {
2014-01-09 20:29:45 -06:00
self.session.add_lint(UnusedImports,
2013-05-21 05:09:22 -05:00
id, p.span,
~"unused import");
}
}
ViewPathList(_, ref list, _) => {
for i in list.iter() {
if !self.used_imports.contains(&i.node.id) {
2014-01-09 20:29:45 -06:00
self.session.add_lint(UnusedImports,
i.node.id, i.span,
~"unused import");
}
}
}
}
}
}
}
}
//
// Diagnostics
//
// Diagnostics are not particularly efficient, because they're rarely
// hit.
//
/// A somewhat inefficient routine to obtain the name of a module.
2013-12-19 21:02:22 -06:00
fn module_to_str(&mut self, module_: @Module) -> ~str {
2013-03-07 17:37:14 -06:00
let mut idents = ~[];
let mut current_module = module_;
loop {
2012-08-06 14:34:08 -05:00
match current_module.parent_link {
2012-08-03 21:59:04 -05:00
NoParentLink => {
break;
}
2012-08-03 21:59:04 -05:00
ModuleParentLink(module_, name) => {
2012-09-19 20:52:49 -05:00
idents.push(name);
current_module = module_;
}
2012-08-26 14:12:05 -05:00
BlockParentLink(module_, _) => {
idents.push(special_idents::opaque);
current_module = module_;
}
}
}
if idents.len() == 0 {
2012-08-01 19:30:05 -05:00
return ~"???";
}
2013-09-01 19:50:59 -05:00
return self.idents_to_str(idents.move_rev_iter().collect::<~[ast::Ident]>());
}
2013-12-08 01:55:28 -06:00
#[allow(dead_code)] // useful for debugging
2013-12-19 21:02:22 -06:00
fn dump_module(&mut self, module_: @Module) {
debug!("Dump of module `{}`:", self.module_to_str(module_));
debug!("Children:");
self.populate_module_if_necessary(module_);
2013-12-21 17:32:44 -06:00
let children = module_.children.borrow();
for (&name, _) in children.get().iter() {
2014-01-31 14:25:11 -06:00
debug!("* {}", token::get_ident(name).get().to_str());
}
debug!("Import resolutions:");
let import_resolutions = module_.import_resolutions.borrow();
for (name, import_resolution) in import_resolutions.get().iter() {
2013-04-30 15:35:01 -05:00
let value_repr;
match import_resolution.target_for_namespace(ValueNS) {
2012-08-20 14:23:37 -05:00
None => { value_repr = ~""; }
2012-08-26 14:12:05 -05:00
Some(_) => {
value_repr = ~" value:?";
// FIXME #4954
}
}
2013-04-30 15:35:01 -05:00
let type_repr;
match import_resolution.target_for_namespace(TypeNS) {
2012-08-20 14:23:37 -05:00
None => { type_repr = ~""; }
2012-08-26 14:12:05 -05:00
Some(_) => {
type_repr = ~" type:?";
// FIXME #4954
}
}
2014-01-31 14:25:11 -06:00
debug!("* {}:{}{}", token::get_ident(*name).get().to_str(),
value_repr, type_repr);
}
}
}
pub struct CrateMap {
def_map: DefMap,
exp_map2: ExportMap2,
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
trait_map: TraitMap,
external_exports: ExternalExports,
last_private_map: LastPrivateMap,
}
/// Entry point to crate resolution.
pub fn resolve_crate(session: Session,
lang_items: @LanguageItems,
2013-09-27 21:46:09 -05:00
crate: &Crate)
-> CrateMap {
2013-09-27 21:46:09 -05:00
let mut resolver = Resolver(session, lang_items, crate.span);
resolver.resolve(crate);
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
let Resolver { def_map, export_map2, trait_map, last_private,
2013-11-28 14:22:53 -06:00
external_exports, .. } = resolver;
CrateMap {
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
def_map: def_map,
exp_map2: export_map2,
trait_map: trait_map,
external_exports: external_exports,
last_private_map: last_private,
}
}