Re: Issue 1035 in include-what-you-use: Transitive includes not analyzed?

[notifi...@include-what-you-use.org]

Comment #2 on issue 1035 by carlosgalvezp: Transitive includes not analyzed?
https://github.com/include-what-you-use/include-what-you-use/issues/1035

Thanks, I'm aware of the option, my question is more of "why" it's like that?

Existing behavior in other tools, like compilers (GCC, Clang) and clang-tidy is that they analyze all headers transitively by default (ok, one has to set the HeaderFilterRegex to * in clang-tidy, but it's fairly low effort). To obtain the same behavior from IWYU, one has to manually specify all the header files that should be analyzed, which is much more troublesome. Would it make sense to add an option similar to clang-tidy to allow users to analyze all transitive headers?

[notifi...@include-what-you-use.org]

Comment #3 on issue 1035 by kimgr: Transitive includes not analyzed?
https://github.com/include-what-you-use/include-what-you-use/issues/1035

> [...] behavior in other tools, like compilers (GCC, Clang) and clang-tidy is that they analyze all headers transitively by default

I wasn't around for the initial design, but I suspect it works this way for two reasons:

* simplicity
* avoiding strange loops

The compiler and most clang-tidy checks do not analyze or modify the include graph, so it's trivial/obvious for them to analyze the transitive closure of a translation unit's files. For IWYU it's not so clear. Suggesting a change to an included header can invalidate the analysis for the main source file, and there are several degenerate cases (e.g. cyclic includes, same header reachable via different branches in the include tree, and with different preprocessor state, etc).

I have a friend who set up a really nice IWYU metrics and analysis website for a large closed-source code base, and the strategy he suggested rang really true with me:

* First analyze all header files individually, assuming they should stand on their own. Make them IWYU clean.
* Then analyze shared components, and make them IWYU clean
* Finally analyze "top-level" or "root" components

That way each step builds on a clean base. If we try and start with everything at once, or top-level components first, shared headers will cause so much noise that it's hard to see through. And the analysis of lower-level components might need to undo changes made on a higher level before. So starting from the bottom up seems to make sense.