-
Notifications
You must be signed in to change notification settings - Fork 1.7k
module_name_repetitions
: don't warn if the item is in a private module.
#13444
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
Conversation
…ule. Fixes <rust-lang#8524>. There is still a warning (as there should be) if the item is reexported by name, but not by glob; that would require further work to examine the names in the glob, and I haven't looked into that. Credit to @Centri3 for suggesting approximately this simple fix in <rust-lang#8524 (comment)>. However, per later comment <rust-lang#8524 (comment)>, I am not making it configuration-dependent, but *always* checking public items in public modules only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks! ❤️ 🌈 And sorry for the delay, I'm not sure why nobody picked this up before 😅
This may affect #13541
/// and `array::from_ref` rather than `array::array_from_ref`. | ||
/// | ||
/// ### Known issues | ||
/// Glob re-exports are ignored; e.g. this will not warn even though it should: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the inclusion of this Known issues section
@bors r+ |
`module_name_repetitions`: don't warn if the item is in a private module. Fixes <#8524>. There is still a warning (as there should be) if the item is reexported by name, but not by glob; that would require further work to examine the names in the glob, and I haven't looked into that. Credit to `@Centri3` for suggesting approximately this simple fix in <#8524 (comment)>. However, per later comment <#8524 (comment)>, I am not making it configuration-dependent, but *always* checking public items in public modules only. changelog: [`module_name_repetitions`]: don't warn if the item is in a private module.
@bors r- |
Just making sure @kpreid, why are there so many removed instances of this lint on lintcheck? Like this one:
The module is called |
☀️ Try build successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
The module is not public. In the parent its items are re-exported, and so their public paths have no repetition: mod lookup;
pub use lookup::{LookupContinuation, LookupResult, SplitDwarfLoad}; This is precisely an example of the false positive that this PR is intended to fix. There may also be cases where the item’s public path does contain a repetition, and the instance of the lint firing on the item has disappeared, but the lint still fires on the re-export. For example, in pub mod foo {
mod builder {
pub struct FooBuilder;
}
pub use builder::FooBuilder;
} the lint used to fire on |
I've verified a some more of these removed positives, and you're right! Everything's correct now, thanks for your contribution. @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fixes #8524.
There is still a warning (as there should be) if the item is reexported by name, but not by glob; that would require further work to examine the names in the glob, and I haven't looked into that.
Credit to @Centri3 for suggesting approximately this simple fix in #8524 (comment). However, per later comment #8524 (comment), I am not making it configuration-dependent, but always checking public items in public modules only.
changelog: [
module_name_repetitions
]: don't warn if the item is in a private module.