I agree with Michael that it's complicated. I honestly don't expect the
compiler (or other static analyzer) to sort it out.

Problems often emerge from a mix of definition and usage and not either on
its own. And whether something is actionable is certainly not something any
compiler or analysis tool can be confident about to the degree we need for
always-on warnings.

I'm hoping we eventually get a mix of wider use of JSON based diagnostic
output (like SARIF) and some more standard ways to suppress diagnostics as
appropriate. I'm fine playing small ball with existing workflows (i.e.,
-Wall -Werror), but I expect dissatisfaction with tradeoffs as long as we
focus on these workflows.

Bret

On Mon, Dec 25, 2023, 01:39 Michael Spencer via SG15 <sg15_at_[hidden]>
wrote:

> 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
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>