Hi, On 2024-02-12 16:46:55 -0500, Tom Lane wrote: > Peter Eisentraut <pe...@eisentraut.org> writes: > > Approaches like that as well as the in-tree pgrminclude work by "I > > removed the #include and it still compiled fine", which can be > > unreliable. IWYU on the other hand has the compiler tracking where a > > symbol actually came from, and so if it says that an #include is not > > used, then it's pretty much correct by definition. > > Well, it might be correct by definition for the version of the code > that the compiler processed. But it sounds to me like it's just as > vulnerable as pgrminclude to taking out #includes that are needed > only by #ifdef'd code sections that you didn't compile.
I think pgrminclude is far worse than IWYU - it *maximizes* reliance on indirect includes, the opposite of what iwyu does. I share concerns about removing includes for platform/config option specific code, but I think that it'd not take too many annotations to address that. I think the proposed patch shows some good changes that are painful to do by hand, but easy with iwyu, like replacing builtins.h with fmgrprotos.h, replacing includes of heapam.h/heap.h with table.h etc where appropriate. While I can see applying some targeted changes without more work, I don't really see much point in applying a lot of the other removals without actually committing to adding the necessary IWYU annotations to our code to make iwyu actually usable. Greetings, Andres Freund
