The defs.h / common-defs.h / server.h rule

[Simon Marchi]

Hi all,

We currently have a rule [1] saying that all .c/.cc file must include
one of defs.h, common-defs.h or server.h, depending on where they are,
and that no header should include them.

I was wondering about why that rule exists, and if it is still relevant
today.

The reason I am asking is that I'm usually working on GDB in an editor
that uses clangd behind the scenes, which is really good at showing
accurate errors and warnings in real time.  Unfortunately, the
experience is bad for headers when headers don't include what they use.
Since headers in GDB don't include defs.h, but use a lot of things
defined there (or in files included transitively), editing headers in
GDB is really bad.

Could we switch to having headers include what they use?  There might be
some edge cases where we can't do that with header files used both in
GDB and GDBserver context, but it would still be nice to make the
experience better for all header files used in only one (which is the
majority).

As an example, I'm attaching some before / after screenshots of what it
looks like when editing objfiles.h before including defs.h at the top
and after.

Before someome says "it's your tools' fault, your tools are bad": I
know.  There has been some requests [2] to improve clangd for
non-self-contained headers.  Having a feature like that would help here,
but I don't think I can expect it any time soon, and I don't have the
skills required to do it.  OTOH, I think that GDB's style here is a bit
odd and goes against the typical Good Practices (tm).

Simon

[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Include_Files
[2] https://github.com/clangd/clangd/issues/1534
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Before.png
Type: image/png
Size: 316538 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/gdb-patches/attachments/20240217/a5013477/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: After.png
Type: image/png
Size: 158187 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/gdb-patches/attachments/20240217/a5013477/attachment-0003.png>