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.

Anyway, tagging could be interesting, but I don't know that extending
existing `-Wall` would be popular. And I think identifying the driver or
provider or author (etc.) of the message would likely be more interesting
than the tagging feature. As a thought exercise, consider looking at some
example SARIF output from existing toolchains and consider how we would
expect one of these messages to appear as an entry. Then think what kind of
structures would enable the compiler to support that expectation.

Bret

On Mon, Oct 14, 2024, 17:44 Mathias Stearn via SG15 <sg15_at_[hidden]>
wrote:

> You might want to allow some way to group these since compiler warnings
> are often turned on and off by groups in addition to specific flags. At the
> very least, it should be possible for each library to offer a group for all
> of its warnings, but huge libraries may want their own sub groups as well.
> One way would be to offer an overload that takes an initializer_list of
> tags so you could do
>
> std::constexpr_warning({"all", "format", "format-too-many-args"}, "Format
> string consumed {} arguments but {} were provided.", current_arg, total);
>
> Which means that any of -Wall, -Wformat, or -Wformat-too-many-args (with
> -W replaced with a clash-free prefix) would turn that on, but it could also
> be specifically disabled with -Wno-format-too-many-args.
>
> I could also imagine a lighter-weight way of specifying these by taking a
> space or comma separated list in the string. If you go that route,
> obviously you would need to allow space or comma.
>
>
> On Mon, Oct 14, 2024 at 10:43 PM Zach Laine via SG15 <
> sg15_at_[hidden]> wrote:
>
>> For the tag in particular, this seems like just the right kind of
>> limitation.
>>
>> Zach
>>
>> On Mon, Oct 14, 2024 at 3:05 PM Barry Revzin via SG15
>> <sg15_at_[hidden]> wrote:
>> >
>> > Hey Tooling Study Group,
>> >
>> > I have this paper, P2758 (latest currently:
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2758r3.html),
>> which proposes low-level utilities for emitting messages during constant
>> evaluation time.
>> >
>> > Those messages have three kinds (print, warning, and error) and can
>> also be tagged. The intent of the tagging is to give the user the kind of
>> control typically reserved for the compiler. That is, the format library
>> can diagnose something with:
>> >
>> > std::constexpr_warning("format-too-many-args", "Format string consumed
>> {} arguments but {} were provided.", current_arg, total);
>> >
>> > And that'll emit a compiler warning that maybe can be explicitly
>> enabled (with some flag like -Wformat-too-many-args) or disabled (with some
>> flag like -Wno-format-too-many-args). And possibly likewise with #pragmas
>> for local blocks. Of course the actual mechanism is implementation-defined
>> and it's likely the flags won't be exactly that so that they won't clash
>> with actual implementation warnings.
>> >
>> > Evolution was happy with this proposal, but wanted you all to take a
>> look at it for its use of tagging to make sure that this is a viable path.
>> Right now, the paper's restriction on tagging is that it only contains,
>> basically, a-z, A-Z, 0-9, an underscore, or a hyphen — although it
>> presently also allows empty strings, which I'll change in a subsequent
>> revision. That restriction avoids having to really deal with unicode stuff,
>> while also matching the set of characters currently used in compiler flags
>> anyway, so doesn't seem like it's cutting off anything useful to me.
>> >
>> > Thanks in advance for the feedback,
>> >
>> > Barry
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>