[libc-commits] [libc] [libc] Make two include/llvm-libc-types/ headers more self-contained. (PR #128094)

[Roland McGrath via libc-commits]

frobtech wrote:

> * imaxdiv_t.h needs intmax_t. Get it from <stdint.h> directly instead of relying on prior inclusion inside generated inttypes.h.

This is fine.  In general we should not have transitive includes from `llvm-libc-types` headers.  But the compiler-provided headers are a special exception to that (`<stddef.h>`, `<stdint.h>`, `<stdarg.h>`).

> * include <termios-macros.h> for struct termios to get the #defined constant. We do allow inclusion of macro headers from types headers in other places.

I don't think we should do this, for two reasons.
 1. Name space: the point of per-type headers is that define only what must be defined to make that type complete.  There may well be places where the type must be available, but the public header isn't supposed to define all the macros that are associated with that type's full API.
 2. Build management: it's currently manually plumbed in CMake what headers rely on which others; but it's not that way in the Fuchsia build, and eventually we should find a way to move the CMake build in the same direction.  That is, pretty much all the dependencies between headers go from a root public `<foo.h>` header directly to a set of implementation headers in `llivm-libc-types` and `llvm-libc-macros`.  The YAML files are the source of truth that produces all the `#include` directives in a fully-generated header (no `.h.def` file, which is where we want to get nearly all of the headers to eventually).  This lets us use automation to manage the build and installation rules for all the headers, rather than manual maintenance of lists of the implementation headers used by the public headers.

So the contrary change I would recommend here is to remove `termios.h.def` and its `header_template` line in `termios.yaml`.


https://github.com/llvm/llvm-project/pull/128094