From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: backend *.c #include cleanup (IWYU) |
Date: | 2024-02-12 21:46:55 |
Message-ID: | 2356244.1707774415@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(at)eisentraut(dot)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.
On the whole, our experience with automated #include removal is
pretty awful. I'm not sure I want to go there again.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Luzanov | 2024-02-12 21:53:50 | Re: Psql meta-command conninfo+ |
Previous Message | Bharath Rupireddy | 2024-02-12 21:31:39 | Re: Fix a typo in pg_rotate_logfile |