Hi,
On 2024-02-12 16:46:55 -0500, Tom Lane wrote:
> Peter Eisentraut <peter@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