From: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Subject: | Re: [PATCH] Remove unused #include's in src/backend/commands/* |
Date: | 2025-10-08 18:41:30 |
Message-ID: | CAJ7c6TNw9jym8-=kbpViL9MB2mRAxcdNhmFGFDo8c+jUiLRZVg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Nathan,
> Seems reasonable to me. Most of these seem to be recent additions since
> last year's round of IWYU commits. Any reason to limit this to
> src/backend/commands? Why not tackle the whole tree at once?
The main problem here is that clangd is a language server, which means
I see errors reported by it when I open a particular file in a text
editor. To go manually over ~2500 .c/.h files we have and then see
what will break on CI because of an #ifdef (as it was with the patch
v1) doesn't strike me as a great idea :)
In theory there is a way to get clangd warnings for a given file using
a command like this:
# use meson; make sure build/compile_commands.json exists
path/to/bin/clangd --enable-config \
--log=error \
--compile-commands-dir=build \
--check="src/backend/commands/collationcmds.c"
... which can be executed in a loop for all the existing files.
Unfortunately it doesn't work. The command outputs multiple errors,
something about:
```
FAIL: The new replacement overlaps with an existing replacement.
```
¯\_(ツ)_/¯ So far I haven't figured out how to make it work.
Alternatively we could prioritize ~100 .c files which can be checked
manually. Or we can make changes iteratively, as with patches v1/v2.
Personally I prefer multiple small changes to a single but huge one to
be honest.
--
Best regards,
Aleksander Alekseev
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-10-08 18:45:40 | Re: Invalid pointer access in logical decoding after error |
Previous Message | vignesh C | 2025-10-08 18:39:38 | Re: Invalid pointer access in logical decoding after error |