Repository navigation
Change "A non-empty glob must import something with the glob's visibility" to be a lint? #62334
Description
Activity
The error was introduced in #35894 as a part of import modularization, and discussed in one of the related issues, but I can't find where exactly.
The error was introduced by analogy with errors for single imports (and just to be conservative):
mod m { fn f() {} } use m::f; // Doesn't import anything and therefore reports an error. use m::g; // Doesn't import anything and therefore reports an error. use m::*; // Doesn't import anything and therefore reports an error.
The error is not technically necessary, and we should be able to report it as a lint for glob imports while keeping it an error for single imports.
- addedA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyArea: Name/path resolution done by `rustc_resolve` specificallyT-langRelevant to the language teamRelevant to the language team
on Jul 28, 2019 Would this be a "good first issue" or is it complex to fix?
No, not complex.
- Find where "non-empty glob must import something" is reported.
- Replace
span_errwithbuffer_lint(UNUSED_IMPORTS, ...).
- addedE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Oct 17, 2019 I want to do this issue but the problem I have is with a test (ui/imports/reexports) that checks for this error, I don't know the compiler structure so I don't know when compiling this file the lint will not be reported because of the other errors or not. Else I changed the
span_errtobuffer_lint- added a commit that references this issue
on Oct 29, 2019 - added a commit that references this issue
on Oct 29, 2019 - addedA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.and removedA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.
on Dec 21, 2024
Consider the following three examples: A and C are accepted and B has a compilation error. However, the message reported in B looks more like a lint than a compilation error.
A consequence of this error is that adding a non-public function to a module (e.g. the
barin B) may break code that imports from that module. This causes surprises when refactoring.Shouldn't "A non-empty glob must import something with the glob's visibility" be a lint?
The original discussion is here: https://users.rust-lang.org/t/a-non-empty-glob-must-import-something-with-the-globs-visibility-uhhh-okay-but-why
A
B
C