[PATCH] Add readability-duplicate-include check to clang-tidy

[Alexander Kornienko]

On 16 Mar 2015 17:51, "Richard" <legalize at xmission.com> wrote:
>
> ================
> Comment at: clang-tidy/readability/DuplicateIncludeCheck.cpp:62
> @@ +61,3 @@
> +    StringRef SearchPath, StringRef RelativePath, const Module
*Imported) {
> +  if (!SM_.isInMainFile(HashLoc)) {
> +    return;
> ----------------
> alexfh wrote:
> > LegalizeAdulthood wrote:
> > > alexfh wrote:
> > > > What's the reason to limit the check to the main file only? I
think, it should work on all headers as well. Also, sometimes it's fine to
have duplicate includes even without macro definitions in between, e.g.
when these #includes are in different namespaces.
> > > >
> > > > I'd suggest using the same technique as in the IncludeOrderCheck:
for each file collect all preprocessor directives sorted by SourceLocation.
Then detect #include blocks (not necessarily the same way as its done in
the IncludeOrderCheck. Maybe use the presense of any non-comment tokens
between #includes as a boundary of blocks), and detect duplicate includes
in each block.
> > > If I remove the `isInMainFile`, how do I ensure that I don't attempt
to modify system headers?
> > Using `SourceLocation::isInSystemHeader()`.
> Thanks, I'll try that.  The next question that brings to mind is how do I
distinguish between headers that I own and headers used from third party
libraries?

You don't. You detect issues in all headers (even including system ones, as
there are people who develop system headers and need to run analysis on
them). And then clang-tidy filters out warnings in headers the user didn't
ask to analyze by the means of the -header-filter option.
>
> For instance, suppose I run a check on a clang refactoring tool and it
uses `isInSystemHeader` and starts flagging issues in the clang tooling
library headers.
>
> The `compile_commands.json` doesn't contain any information about headers
in my project, only translation units in my build, so it doesn't know
whether or not included headers belong to me or third-party libraries.
>
> http://reviews.llvm.org/D7982
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150316/749b4b47/attachment.html>