Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

uses in crate root shadow crates in inner modules #12612

Closed
mind-zz opened this issue Feb 28, 2014 · 6 comments
Closed

uses in crate root shadow crates in inner modules #12612

mind-zz opened this issue Feb 28, 2014 · 6 comments
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically P-medium Medium priority
Milestone
1.0

Comments

@mind-zz
Copy link

mind-zz commented Feb 28, 2014 

extern crate sync;
use std::sync;

mod inner {  use sync::RWArc;  }

rustc errors:

foo.rs:4:17: 4:28 error: unresolved import: there is no RWArc in std::sync

(rustc 0.10-pre (6720977 2014-02-24 04:11:53 -0800))
@alexcrichton
Copy link
Member

Closing as working as intended. This is what the syntaxes extern crate foo = "bar" and use foo = bar are used for (resolving name conflicts).

@mind-zz
Copy link
Author

mind-zz commented Feb 28, 2014

Even across different modules? It's unintuitive that the use declarations in foo.rs would be affecting the use declarations in inner.rs. Although the problem would be quite apparent if name collisions resulted in an error.

@alexcrichton
Copy link
Member

Oops sorry, misread! That's indeed a bug.

@alexcrichton alexcrichton reopened this Feb 28, 2014
@huonw
Copy link
Member

huonw commented Feb 28, 2014

I think it makes perfect sense to shadow if these were pub use... but since they're not, and so this is very weird (especially as one often puts code in the crate root, and so the uses are necessary).

#7663 and #10884 are similar, but I think this case is a particularly bad consequence of our use rules.

@alexcrichton
Copy link
Member

Nominating. This itself is not a backwards compatibility hazard (it's just a bug), but nearly every tweak I've made to resolve has broken many programs before. Thankfully, this program does not compile:

use std::c_str;

mod foo {
    use c_str;
}

However, I think we should fix this before 1.0 to be sure that we don't accidentally break programs.

@huonw huonw mentioned this issue Mar 2, 2014
Closed
@pnkfelix
Copy link
Member

Assigning 1.0, P-high.

@pnkfelix pnkfelix added this to the 1.0 milestone Mar 13, 2014
alexcrichton added a commit to alexcrichton/rust that referenced this issue Apr 10, 2014
@alexcrichton
rustc: Disallow importing through use statements
b36b2e8 
Resolve is currently erroneously allowing imports through private `use`
statements in some circumstances, even across module boundaries. For example,
this code compiles successfully today:

    use std::c_str;
    mod test {
        use c_str::CString;
    }

This should not be allowed because it was explicitly decided that private `use`
statements are purely bringing local names into scope, they are not
participating further in name resolution.

As a consequence of this patch, this code, while valid today, is now invalid:

    mod test {
        use std::c_str;

        unsafe fn foo() {
            ::test::c_str::CString::new(0 as *u8, false);
        }
    }

While plausibly acceptable, I found it to be more consistent if private imports
were only considered candidates to resolve the first component in a path, and no
others.

Closes rust-lang#12612
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically P-medium Medium priority
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
4 participants
@mind-zz @alexcrichton @pnkfelix @huonw