-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
module_name_repetitions false positive when in private module #8524
Comments
I totally agree with this! Being able to break a module into submodules spread out in several files, and re-exporting them in the original module name is something I find quite useful as projects get larger! Does anyone think there is any merit to this lint when the module that an item is contained in is private? Is there a better way to approach the aforementioned situation which avoids the module name repetition (even if its private)? |
This was fixed for We can move this to the outer |
Good to see this bug report already exists! I was just about to make one after having the same issue! As for @wmmc88 's question, the main rationale for this lint seems to be keeping public API clean, so I think it's fine to allow this by default, but perhaps we take the (inverted) approach of #10917 and add a configuration flag for disallowing it if you want to force yourself to avoid this kind of repetition within your private modules as well? A bit like how you can opt-in to warnings about missing docs on private functions? |
@wmmc88 A follow-up thought though: this lint doesn't (I believe) currently look at anything non- Remembering the obvious, that this lint doesn't apply to private functions, definitely strengthens the case that it shouldn't (by default) apply to private modules either! |
Even for public modules, there are this false positives.
// mod.rs
pub mod self::iter; // iter.rs
pub struct IterSomething {
...
} If I add the following into the clippy configuration file allowed-prefixes = ["..", "Iter"] This is unexpected as the clippy doc declares:
|
Summary
When organizing large modules, I sometimes want to split a module into multiple files, but re-export all of the contents as if the module were one single module. The public interface to the module doesn't have any module name repetitions in my example below, yet the warning is still emitted because the containing module's scope isn't considered.
I believe this lint should be tightened to only emit if the module name that is being repeated is
pub
(and maybepub(crate)
but I trust others to make that judgement call).This affects me often enough that I regularly disable this lint in my projects. This morning, I came up with the idea that maybe the lint could be tightened up in this particular situation.
Lint Name
module_name_repetitions
Reproducer
I tried this code:
I saw this happen:
I expected no warnings to be emitted.
Version
Additional Labels
No response
The text was updated successfully, but these errors were encountered: