In http://reviews.llvm.org/D7982#132666, @LegalizeAdulthood wrote:
> I think there is benefit to checking for redundant includes separately from > include order. > > On many code bases where I've worked the include order is all over the place. > The main barrier in my experience to having a consistent include order > hasn't been one of tools, but getting agreement from the team. For the > llvm/clang code bases the team has already decided on the order of includes, > but for many teams that can start a big political battle. > > However, noone is going to disagree with eliminating redundant includes. Makes sense. See a couple of initial comments below. I have a feeling that some common machinery could be pulled from the llvm-include-order check which could benefit this check as well. I'll try to come up with a specific idea later. ================ Comment at: clang-tidy/readability/CMakeLists.txt:10 @@ -9,2 +9,3 @@ ReadabilityTidyModule.cpp + RedundantInclude.cpp RedundantSmartptrGet.cpp ---------------- I'm not a native speaker, but I have a feeling that "duplicate" is a more suitable word here than "redundant". WDYT? ================ Comment at: clang-tidy/readability/RedundantInclude.h:22 @@ +21,3 @@ +/// +/// Any change in the defined macros in the main file between \c #include +/// directives resets the list of includes used to check for duplicates. ---------------- This description is somewhat confusing. Maybe something along the lines of "Only consecutive #include directives without any other preprocessor directives between them are analyzed"? http://reviews.llvm.org/D7982 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
