[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