On Tue, Oct 15, 2024 at 3:46 AM Corentin <corentin.jabot_at_[hidden]> wrote:

>
>
> On Tue, Oct 15, 2024 at 12:50 AM Bret Brown via SG15 <
> sg15_at_[hidden]> wrote:
>
>> I'm supportive of efforts to help library maintainers and users
>> communicate better, so I like it broadly.
>>
>> I would like to see some field describing the author of the diagnostic,
>> though.
>>
>> If `-Wall` was fully open to extension, I might need to disallow the
>> entire flag from my codebase, unfortunately. It's already sort of breaking
>> deprecation workflows that `-Werror=all` hard errors on any usage of `[[
>> deprecated ]]`. Given that erroring on every usage of a deprecated entity,
>> library authors might as well just delete the deprecated API. I anticipate
>> similar issues with warnings coming from libraries, especially on the
>> initial release of any toolchains that allow libraries to add -
>> `-Wall` warnings in particular.
>>
>> So I am thinking that it might be inappropriate to identify these issues
>> in the same category as toolchains provided diagnostics. Note that this
>> concept of diagnostic issues is modeled in interop standards, like SARIF
>> that was been discussed in SG-15 this summer. Each warning and error is
>> attributable to a specific "driver" like GCC or clang-tidy. So I would
>> expect each author of a given message would do well to self-identity using
>> the name of the relevant project. Then it would be clear that the project
>> "foobar" is emitting a warning and that the compiler is just the messenger.
>> As others in this thread have stated, users would likely like to be able to
>> enable, suppress, and prioritize in groups as well.
>>
>> Conceptually, we also should keep in mind that the `-W` flag has a
>> namespace and toolchains need to add more warnings to it as they see the
>> need. This is similar to how languages tend to reserve symbol names and
>> entire namespaced for themselves. If we allowed any arbitrary line of code
>> to change the quality of implementation of `-Wsomething`, then the
>> toolchain would have to figure out another way to express scope for built
>> in warnings names (A new flag? Namespaced warnings?). And existing users
>> (build system scripts and configurations) would be disrupted as they find
>> out that they needed to express whether they want the open-for-extension
>> `-Wsomething` or the one the toolchains supports and describes in its docs.
>>
>> I don't expect that to be well received. I predict instead that `-Wall`
>> wouldn't go anywhere. I could see some other flag being invented for this,
>> especially if it has some notion of scope so different libraries can
>> identify their warnings without worrying about warning name collisions.
>> Ideally library authors would scope warnings with their library name (since
>> they're providing diagnostics, not the compiler) and then an identifier. To
>> pick an arbitrary flag spelling (`-XYZ`) and an arbitrary library name
>> (`foobar`), something like `-XYZerror=foobar` or
>> `-XYZno-error=foobar::sizes-must-be-divisible-by-sixteen` could work.
>> Possibly even `-XYZerror=*::all`. And the driver in something like SARIF
>> could show "foobar" as the originator of the diagnostic.
>>
>
> [Implementer hat on]
>
> These wouldn't translate to some -Wfoo flag directly (even in WG21 asks
> nicely).
> Instead, it would be either a new flag, or some prefix like -Wuser-foo, or
> something that uses the tag in some way, at the discretion of the
> implementation
> And similarly with everything else, we'd most certainly support flags and
> pragma to disable such warnings and to turn them into errors on a per-tag
> basis - and I suspect we would introduce a group to disable/turn into error
> all such user defined warnings.
> The warning text would equally reflect that the warning is user-generated
> to limit the potential for abuse and confusion.
>
> Whether we want some limited support for user-provided diagnostic groups /
> some wildcard mechanism to affect multiple user-defined warnings at once
> is an interesting question. For this, to be remotely useful, users would
> have to be disciplined. Maybe if we require a group in all cases, we'd
> encourage discipline?
>
> You might find this llvm discussion interesting
> https://discourse.llvm.org/t/exposing-the-diagnostic-engine-to-c/73092/14
>

So there are two examples there:

[[clang::warn_if(condition, "text", "-Wgroup", true, true, false, true)]].

and

  __attribute__((diagnose_if(ch > (2 << sizeof(char) * (CHAR_BIT - 1)),
                                             "can only pass 7-bit ASCII values",
                                              warning, "conversion",
DefaultError)));


Both only seem to add a message to a single group (just "-Wgroup" in the
first, just "-Wconversion" in the second). Do you think there's value in
supporting multiples like Matthias suggested, or is one sufficient?

Also, I guess if we want to be able to attach to existing compiler warning
groups (like "-Wconversion"), the implementation probably needs to
understand what I mean. In the paper example, format-too-many-args was
intended as a user-defined message, so that might need some kind of
distinct introducer on the command line. But conversion shouldn't. Does the
implementation provide an enum? Does it do string matching and decide how
to do this based on whether it recognizes the string?

Similarly, does it make sense to allow (require?) the user to specify
whether this warning falls under -Wall vs -Werror?

Barry