Skip to content

use can't resolve non-pub parent module through super #5248

New issue

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

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

Already on GitHub? # to your account

Closed
brson opened this issue Mar 6, 2013 · 9 comments
Closed

use can't resolve non-pub parent module through super #5248

brson opened this issue Mar 6, 2013 · 9 comments
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically

Comments

@brson
Copy link
Contributor

brson commented Mar 6, 2013

This use statement doesn't resolve:

mod foo {
    pub fn bar() { }
}

mod baz {
    use super::foo;
    fn main() {
        foo::bar();
    }
}

This one does:

mod foo {
    pub fn bar() { }
}

mod baz {
    use super::foo::bar;
    fn main() {
        bar();
    }
}
@brson
Copy link
Contributor Author

brson commented Mar 12, 2013

This is because without pub it's a chained import.

@graydon
Copy link
Contributor

graydon commented Apr 30, 2013

is it? there's only one 'use' in any case, I thought the chained-import restriction only applied there

@brson
Copy link
Contributor Author

brson commented Jun 21, 2013

@graydon I'm not sure what I was thinking with that comment.

@pnkfelix
Copy link
Member

pnkfelix commented Jul 2, 2013

linking to #6143 for unified tracking of resolve

catamorphism added a commit to catamorphism/rust that referenced this issue Sep 9, 2013
@catamorphism
Copy link
Contributor

This seems to be fixed. Checking in a test case.

@catamorphism
Copy link
Contributor

Oh, never mind, I misunderstood the bug. With the unmodified code, I still get:

/Users/tjc/rust/src/test/run-pass/issue-5248.rs:16:8: 16:18 error: unresolved import: found `foo` in `???` but it is private
/Users/tjc/rust/src/test/run-pass/issue-5248.rs:16     use super::foo;
                                                           ^~~~~~~~~~
/Users/tjc/rust/src/test/run-pass/issue-5248.rs:16:8: 16:18 error: failed to resolve import `super::foo`
/Users/tjc/rust/src/test/run-pass/issue-5248.rs:16     use super::foo;
                                                           ^~~~~~~~~~

@catamorphism
Copy link
Contributor

Nominating for milestone 5, production-ready

@catamorphism
Copy link
Contributor

Moved to milestone 5

@alexcrichton
Copy link
Member

Closing as a dupe of #8215. The rules in #8215 would disallow the first program (you can use private sibling modules), and the second program would be disallowed for the same reason.

oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
Add lint on large non scalar const

This PR adds the new lint `non_scalar_const` that aims to warn against `const` declaration of large arrays. For performance, because of inlining, large arrays should be preferably declared as `static`.

Note: i made this one to warn on all const arrays, whether they are in a body function or not. I don't know if this is really necessary, i could just reduce this lint to variables out of function scope.

Fixes: rust-lang#400

changelog: add new lint for large non-scalar types declared as const
oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
Rollup of 5 pull requests

Successful merges:

 - rust-lang#5226 (Add lint for explicit deref and deref_mut method calls)
 - rust-lang#5248 (Add lint on large non scalar const)
 - rust-lang#5430 (Disallow bit-shifting in integer_arithmetic)
 - rust-lang#5466 (large_enum_variant: Report sizes of variants)
 - rust-lang#5468 (Zero single char names)

Failed merges:

r? @ghost

changelog: rollup
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-resolve Area: Name/path resolution done by `rustc_resolve` specifically
Projects
None yet
Development

No branches or pull requests

5 participants