[RFC] Allow to use '#pragma once' where possible

According to Coding Standards, developers of LLVM project must use header guards. I think it is a kind of artificial and outdated restriction, since ALL of the compilers which can build the LLVM support #pragma once. Pragma once - Portability

I propose to allow using #pragma once in new code and make it preferable way (and maybe gracefully replace header guards in existing headers). In my opinion, this little change in the Policy can lower a bit the “code noise” (since the code is made to be read by people).


Using #pragma once seems unnecessarily hostile to other compilers we, or someone else, might want to support in future. I don’t see much tangible benefit for it beyond removing 2 lines per header file.

Actually I can not imagine the compiler, which has c++17 support and does not recognise #pragma once statement.

Yes, classic guards are just two more lines, but there are some disadvantages of this approach.

  • You have to make unique name for guard. Now the path of the files are used, which can be annoying if you move some headers.
  • Sometimes it is difficult to figure out which blocks of code are active in macro-intensive headers.
  • It is not as semantically dedicated as #pragma once.
  • It is just unnecessary noise and verboseness.

C++17 is standard, #pragma once is non-standard. So… I can easily imagine such a compiler.


Wow! According to this table, it seems that C++17 standard is not standard. (*irony*)

Seriously, I do not see any reason to strongly deny #pragma once. I do not say that everyone MUST use it, I just propose to make it acceptable (at least).

Kindly take your snark elsewhere. Standard in this context does not mean prevalent.


I don’t really see a reason why we should use it. It’s not exactly hard to write headers guards, #pragma once is non-standard and has slightly different behaviour on different compilers (one of the reasons it’s non-standard), and in a few years we can probably use C++ modules, which solve a lot more problems and are standard. IMO there is just not enough benefit to warrant this change given that it will probably be irrelevant in a few years.

1 Like

It will take some time until LLVM can start using C++ modules.

I switched a long time ago from headers guards to pragma once. Header guards are verbose and error prone. There were too many unnoticed copy-and-paste errors.

1 Like

Clang’s -Wheader-guard is your friend there, unless you butcher your header guards enough that they’re both have an edit distance of more than 50% from the other.

1 Like

Clang’s -Wheader-guard is your friend there

This looks like a crutch to me (I’m part of the crowd that is quite annoyed by these guards as well).

Unless we know of a platform we support that does not support #pragma once, I have a hard time seeing why we should shy away from adopting such facility. The argument about a compiler we “might want to support in future” comes across as really dubious to me.

1 Like

The obvious experiment is to switch one file to pragma once and wait for the buildbots to scream.

I don’t understand why header guards causes code noise. It only takes 3 lines.

Also since #pragma is not standard, it may be possible that the compiler will have some problem with it. For example, the modules have problems with #pragma. e.g., [C++20][Modules] '#pragma once' is not well supported · Issue #58532 · llvm/llvm-project · GitHub and modules: `#pragma once` must appear before `#ifdef` when using `-fmodules` · Issue #38532 · llvm/llvm-project · GitHub.

1 Like

gcc and clang resolve symlinks when evaluating #pragma once, whereas MSVC doesn’t, so it’s inconsistent across platforms. I don’t think that’s a big concern for LLVM, but it was for Meta’s internal build system and led to #pragma once being discouraged for cross-platform builds. The Google and Chrome style guides also ban #pragma once, FWIW.

To be clear: I’m not bother by “noise” as in “it is annoying to read”, but rather as it is 3 lines I need to update every time I rename or move a file (maybe I’m doing more refactoring than most…).

(your mention about issues with modules, as well as behavior differences with symlinks mentioned by @smeenai look to me like very compelling argument to not allow this pragma).