gribozavr2 added inline comments.
================ Comment at: clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:29 + + bool isHeader() const { + return llvm::StringSwitch<bool>(Extension) ---------------- njames93 wrote: > gribozavr2 wrote: > > I think we should consider any file other than the main file to be a header > > (anything brought in by `#include`). Projects have lots of different > > convention -- for example, LLVM uses a `.inc` extension for some generated > > files and x-macro files. The standard library does not have any extensions > > at all (and I'm sure some projects imitate that) etc. > I agree in part, but there is one case that I didn't want to happen and that > is when clang-tidy is ran as a text editor plugin. Often it will blindly > treat the current open file as the main file which would lead to a lot of > false positives, Would a better metric being matching on file extensions not > corresponding to source files (c, cc, cxx, cpp)? > I agree in part, but there is one case that I didn't want to happen and that > is when clang-tidy is ran as a text editor plugin. Does that really happen? That sounds like broken editor integration to me, because this is not how C++ without modules works... > Would a better metric being matching on file extensions not corresponding to > source files (c, cc, cxx, cpp)? Yes, I think that would be better, if we have to sniff file extensions. ================ Comment at: clang-tools-extra/clang-tidy/misc/MissingHeaderFileDeclarationCheck.cpp:75 + continue; + if (AnyHeader || File->NamePart.equals_lower(ThisFile->NamePart)) + return; // Found a good candidate for matching decl ---------------- njames93 wrote: > gribozavr2 wrote: > > This heuristic should be a lot more complex. In practice people have more > > complex naming conventions (for example, in Clang, Sema.h corresponds to > > many files named SemaSomethingSomething.cpp). > > > > I think there is a high chance that checking only a header with a matching > > name will satisfy too few projects to be worth implementing. > > > > On the other hand, if you could use C++ or Clang modules to narrow down the > > list of headers where the declaration should appear, that would be a much > > stronger signal. > That is the reason I added the CheckAnyHeader option. For small projects the > matching name would be usually be enough, but for big complex projects there > is no feasible check that would work. Falling back to making sure every > external definition has a declaration in at least one header will always be a > good warning That's the thing -- due to the lack of consistency in projects and style guides for C++, I think most projects will have to turn on CheckAnyHeader. We get implementation complexity in ClangTidy, false positives in high-profile projects, force users to configure ClangTidy to work well for their projects (unless we set CheckAnyHeader=1 by default... which then nobody would flip back to zero), and little benefit for end users. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D73413/new/ https://reviews.llvm.org/D73413 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits