Template expansion in a template from "system" headers doesn't trigger a
warning today. Can we preserve that behavior for modules? With compiler hat
on, we might not want to, but it's likely to cause headaches for stdlib
authors, and certainly for library authors less careful than stdlib
authors.



On Fri, Dec 22, 2023 at 5:46 PM Michael Spencer <bigcheesegs_at_[hidden]>
wrote:

> On Fri, Dec 22, 2023 at 9:13 AM Steve Downey via SG15 <
> sg15_at_[hidden]> wrote:
>
>> Marking external headers with -isystem is a common strategy for dealing
>> with warning suppression for files outside your control. This can be a
>> mistake as it can suppress warnings from misuse such as conversion in std::
>> optional, but such are the tradeoffs for false positives.
>> If module interfaces are built as part of a project do we need mechanisms
>> to suppress warnings? Standard libraries use pragmas to mark themselves,
>> but most libraries will and should not?
>>
>> Thoughts raised due to
>> https://lucisqr.substack.com/p/the-warnings-you-never-saw -- which I
>> have issues with and have not completely verified.
>>
>
> Clang already has `-fsystem-module` for Clang modules. Although with C++20
> named modules being separate TUs you might not need it, the build system
> can just pass `-Wnone`. Although there are some warnings that are emitted
> even in system headers/modules.
>
> Being a system module does have a few other semantics in Clang, but I
> don't think any of them would apply to C++20 named modules.
>
> - Michael Spencer
>