<p dir="ltr"><br>
On 16 Mar 2015 17:51, "Richard" <<a href="mailto:legalize@xmission.com">legalize@xmission.com</a>> wrote:<br>
><br>
> ================<br>
> Comment at: clang-tidy/readability/DuplicateIncludeCheck.cpp:62<br>
> @@ +61,3 @@<br>
> +    StringRef SearchPath, StringRef RelativePath, const Module *Imported) {<br>
> +  if (!SM_.isInMainFile(HashLoc)) {<br>
> +    return;<br>
> ----------------<br>
> alexfh wrote:<br>
> > LegalizeAdulthood wrote:<br>
> > > alexfh wrote:<br>
> > > > 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.<br>
> > > ><br>
> > > > 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.<br>
> > > If I remove the `isInMainFile`, how do I ensure that I don't attempt to modify system headers?<br>
> > Using `SourceLocation::isInSystemHeader()`.<br>
> 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?</p>
<p dir="ltr">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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> <a href="http://reviews.llvm.org/D7982">http://reviews.llvm.org/D7982</a><br>
><br>
> EMAIL PREFERENCES<br>
>   <a href="http://reviews.llvm.org/settings/panel/emailpreferences/">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
><br>
><br>
</p>