C++ Logo

sg15

Advanced search

Re: "external" modules and warnings

From: Michael Spencer <bigcheesegs_at_[hidden]>
Date: Sun, 24 Dec 2023 22:38:44 -0800
On Fri, Dec 22, 2023 at 5:43 PM Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:

> On Fri, Dec 22, 2023, 18:46 Steve Downey <sdowney_at_[hidden]> wrote:
>
>> A -Wnone on what translation unit?
>>
>
> When translating the module source that is from "the system".
>
> Example at hand is where `std::optional<int16_t> c{300000};` is warnings
>> clean because the template is in the system header file. Now, this is a
>> case where it probably really ought to warn, but doesn't.
>>
>
> I would expect an instantiation that happens because of the local code to
> warn, yes.
>
> If compilers don't warn on that today I'd consider it a bug.
>

It's not that simple. Clang looks at the source location for a diagnostic,
and if that source location points at a system header it may suppress the
warning. At that point Clang doesn't know why the warning is getting
emitted. I don't think there's a programmatic way to tell if you're in a
situation where the user of a type is at fault for the warning or not. Even
if you look at if it involves a dependent type or not, it could still be
something the user can't do anything about, and thus useless to warn on.

- Michael Spencer


>
> But it's also a case where previously clean code is going to fail, but
>> there are probably cases where the warning is triggered by something the
>> client can't control.
>>
>
> Right, a warning created by an instantiation in the module source for a
> "foreign" module probably shouldn't warn.
>
> Daniel
>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

Received on 2023-12-25 06:38:58