LLVM coding standards and order of includes

According to the LLVM coding standards,

Immediately after the header file comment (and include guards if working on a header file), the minimal list of #includesrequired by the file should be listed. We prefer these #includes to be listed in this order:

  1. Main Module Header
  2. Local/Private Headers
  3. llvm/...
  4. System #includes
    If a program is using LLVM, and also using a third-party library such as GMP, where would the coding standard have the GMP include be placed relative to the above order?

The LLVM coding conventions are really intended for LLVM's code itself,
they probably don't cover many situations that would arise when using LLVM
code in broader applications like this... (nor is it likely we'd want to
add wording to the style guide to clarify those use cases, unfortunately).

That said, we do have one (zlib compression?) or two (maybe md5 too?)
external libraries used in LLVM, I imagine they get bundled in with the
system includes, but I've not looked (& given that there aren't many, they
might not be done in any consistent/deliberate manner)

- Dave

Generally it is safer to include ISO headers first (using the ‘#include <…>’ form) so as to minimise the possibility that a later user declaration or macro definition interferes with the correctness of the Standard libraries. It also tends to make pre-compiled header implementations faster and more shareable across a larger set of files.

I would like to suggest revising the LLVM coding standard to place the “System #includes” first.

MartinO

Like David says, if it’s not part of LLVM, the LLVM coding style doesn’t really apply.

However, I would consider any header that is not part of your own project, and not part of LLVM as “system” - whether it REALLY is a system header, or part of some package you’ve installed on the system to support your development is probably not really relevant.

Generally it is safer to include ISO headers first (using the ‘#include
<...>’ form) so as to minimise the possibility that a later user
declaration or macro definition interferes with the correctness of the
Standard libraries. It also tends to make pre-compiled header
implementations faster and more shareable across a larger set of files.

As a complete aside, I'm curious which implementation of precompiled
headers you're referring to. The only one I'm familiar with is MSVC's which
requires a designated PCH that must be first, not just earlier. Generally
we won't put a system header first, we'll put the corresponding .h for this
.cpp file first - as a way to test that that header is standalone (ie:
doesn't depend on any other inclusions before it)

(& FWIW Clang's modules support is a more general form of PCH that doesn't
have these limitations - C++ support is ongoing, though)

Yes, the PCH implementations I was thinking of are MSVC and GCC. Despite working with CLang/LLVM all the time now, I have not actually used its PCH implementation so I don’t know how it behaves - I really should try it out.

In the past I have had some very nasty bugs that were very difficult to analyse, and it turned out that a user declaration or macro had interfered with the behaviour of the ISO headers that were included after it. In one case a C++ program ended up with a very subtle overloading change that resulted after a “clever” user data type was introduced that unintentionally altered how the overloading resolved in the definitions of some of the template function implementations.

All the best,

MartinO