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
>