Re: remove pgrminclude?

[Peter Eisentraut]

On 09.12.24 18:20, Tom Lane wrote:
     walsender.h should depend on xlog.h, not vice versa.  (Actually, the
     inclusion was circular until a couple hours ago, which was even sillier;
     but Bruce broke it in the expedient rather than logically correct
     direction.)  Because of that poor decision, plus blind application of
     pgrminclude, we had a situation where half the system was depending on
     xlog.h to include such unrelated stuff as array.h and guc.h.  Clean up
     the header inclusion, and manually revert a lot of what pgrminclude had
     done so things build again.
     
     This episode reinforces my feeling that pgrminclude should not be run
     without adult supervision.  Inclusion changes in header files in particular
     need to be reviewed with great care.  More generally, it'd be good if we
     had a clearer notion of module layering to dictate which headers can sanely
     include which others ... but that's a big task for another day.
In short, pgrminclude turned a small human error into a giant mess
that required half a day's work to clean up, because it had no idea
which of some redundant-looking includes were reasonable to get
rid of and which weren't.

I am worried that IWYU might be prone to similar mess-amplification.
Perhaps it has better heuristics as a result of doing more thorough
semantic analysis, but heuristics are still only heuristics.

One thing that I would look favorably on, given the mistakes we made
in 2011, is automatic detection of circular #include's.  Do you happen
to know whether IWYU complains about that?

IWYU is built on compiler infrastructure and tracks where things are 
declared and where they are used and then suggests you to include 
exactly the header files where the things you use are declared (rather 
than some other header file that happens to pull in the one you actually 
need) and suggests to remove the includes that don't provide any 
declarations that you use.  So it is not really a heuristic, it is 
perfectly accurate, barring bugs or complicated edge cases (cough, 
cough, CppAsString2()), assuming one agrees with that goal.

If you have two headers that circularly include each other, and you have 
the normal multiple-inclusion-guards, then one of the includes won't 
contribute anything to the overall set of declared things, so it would 
most likely be suggested for removal.  That's not exactly the same thing 
as actual circular include detection, but it will indirectly tell you 
about it.