[clang] [C++20] [Modules] Warn if we found #include <filename> in module purview (PR #69555)

Iain Sandoe via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 19 01:03:02 PDT 2023


iains wrote:

> > When I suggested this, it was an intention to limit it to C++ std library headers. Do we not have some existing mechanism that knows which headers are in this category (for typo correction etc?)
> 
> As far as I can reach, we don't have such a mechanism. 

Ah, that's unfortunate, if we could limit the initial warning to items within the language and only expand it if there are reported problems elsewhere it would be easier.

>I was wondering if we can do this by using `# pragma GCC system_header`. But it shows that the libcxx don't always use this pragma.

agree that this would seem unreliable/unusable.

> Also I feel it makes sense to not include other system headers. e.g., in our coding standards, we need `<>` to include boost headers and the sys headers (e.g., #include <sys/mman.h>)

yeah - that is both a good case for making it more general and also a warning that project policies could do something unexpected.

> > My concern with making it more general is that it then covers things like frameworks which are also included like `<Framework/....>` (of course, it's also probably not what was intended there as well)
> > Let's add @Bigcheese to the reviewers, for an opinion on Frameworks
> 
> What do you mean by frameworks? Do you mean something used in apple modules? If yes, the current implementation shouldn't cover that. Since I add this warning only after we handled import.

(in this context) Framework headers are like system (or user headers) but searched by a different mechanism (so they are `#include-`ed).    In principle, the same constraints should apply - `<Framework/....>` indicates a "system" header and _**probably**_ should not be included in the module purview.


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


More information about the cfe-commits mailing list