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.

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

Strange behavior with unused imports #15449

Closed
zwarich opened this issue Jul 5, 2014 · 10 comments
Closed

Strange behavior with unused imports #15449

zwarich opened this issue Jul 5, 2014 · 10 comments
Labels
A-resolve Area: Name resolution

Comments

@zwarich
Copy link

zwarich commented Jul 5, 2014

This program is currently accepted:

use A::B;

mod A {
    pub struct B { n: int }
    fn B() { }
}

fn main() {
}

but this program, which adds a use of B(), is not:

use A::B;

mod A {
    pub struct B { n: int }
    fn B() { }
}

fn main() {
    let _ = B();
}
@zwarich
Copy link
Author

zwarich commented Jul 5, 2014

I found this while trying out cases for #15443.

@pcwalton
Copy link
Contributor

pcwalton commented Jul 5, 2014

What is the error?

@huonw huonw added the A-resolve label Jul 5, 2014
@zwarich
Copy link
Author

zwarich commented Jul 5, 2014

Sorry, didn't include it:

test.rs:1:5: 1:10 error: type `B` is inaccessible
test.rs:1 use A::B;
              ^~~~~

@pcwalton
Copy link
Contributor

pcwalton commented Jul 5, 2014

Interesting. I believe that both programs should be accepted and the privacy pass is wrong here. Imports are "greedy" and resolve to as many namespaces as they have access to.

@zwarich
Copy link
Author

zwarich commented Jul 5, 2014

Adding a pub to the fn B() { } makes the error go away.

@pcwalton
Copy link
Contributor

pcwalton commented Jul 5, 2014

Yup. I think the privacy pass is getting confused by the differing privacy when multiple namespaces are involved.

@frewsxcv
Copy link
Member

frewsxcv commented Feb 3, 2015

Just tried running this and confirm this is still an issue.

@steveklabnik
Copy link
Member

By changing int to i32, this error persists today.

I feel like this is a duplicate of another ticket, but I cannot find it right now.

@petrochenkov
Copy link
Contributor

I feel like this is a duplicate of another ticket, but I cannot find it right now.

#12334 and it's closed.
This "strange" behavior is intentional currently.

@steveklabnik
Copy link
Member

Closing the .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Area: Name resolution
Projects
None yet
Development

No branches or pull requests

6 participants