On Tue, 15 Oct 2024 at 18:53, Aaron Ballman via SG15 <sg15_at_[hidden]>
wrote:

> Thanks! FWIW, users do want this sort of capability, but the fact that
> no implementation has yet to add a feature with bells and whistles is
> because the problem is not easy to solve. I'm highly skeptical that
> this is something WG21 should be standardizing at all currently; it's
> firmly in the realm of QoI and different implementations have
> different needs (and our needs evolve over time). The only form of the
> feature I would consider supporting would be one that accepts the
> message to be printed during constant evaluation and nothing else.
> Anything with more bells and whistles will be problematic in practice.
>
> Practical implementability problems include:
> * Different implementations have different severities for diagnostics
> (error, warning, note, remark, no severity distinctions, etc)
>

We already have a distinction between #error and #warning, how is this any
different?

constexpr_print just outputs a message at compile time (which you've said
is fine).
constexpr_warning outputs a diagnostic message with similar behaviour to
#warning. If the implementation can't do non-fatal diagnostic messages,
i.e. warnings as opposed to errors, then presumably that's already a
problem for #warning. The behaviour for constexpr_warning can be consistent
with that.
constexpr_error outputs a diagnostic message with similar behaviour to
#error, rendering the program ill-formed.



> * Different implementations have different rules for additional
> effects on diagnostics (default ignore, default error, SFINAE trap,
> etc)
>

I don't think I understand this point.


> * Different implementations have different ways to identify
> diagnostics (unique numeric identifier, warning group, no
> identification at all, etc)
>
* Some implementations have the ability to group diagnostics together,
> other implementations don't
>


Those with a unique identifier could give a single ID to all
constexpr_warning diagnostics, and they would all be disabled or all
enabled together. That would be conforming (the grouping and suppression
are only recommended practice).
Those with no grouping could do something similar, with a
-Wno-constexpr-warnings that affects them all. That would be conforming.

Implementations that want to give better user experiences could have
options that use the tag-str to be more fine-grained. But it wouldn't be
required for conformance.

"Some implementations could not implement the Recommended practice" is
fine, that's how normative encouragement is supposed to work.



> * Some implementations localize their diagnostics, so trying to make
> user-defined diagnostics look like compiler diagnostics can cause
> consistency issues
>

Isn't that already the case for static_assert messages? Would this be
worse? Couldn't we cope?


* Not all diagnostics are emitted to a terminal (there may be
> limitations on what can be emitted as a diagnostic depending on
> whether the diagnostics are being emitted to a terminal, to a list box
> UI, to a SARIF file, etc)
>

Isn't that also already the case for static_assert messages?

If I do static_assert(false, "{ lol: { \"wat [ "); then the compiler
already needs to be able to output that as SARIF without producing
corrupted JSON.



>
> These sorts of things are why I only support a very simple
> standardized interface, if anything. Trying to standardize something
> with more bells and whistles will run into problems where not every
> implementation can support it or will be willing to change their
> diagnostic practices to support it.
>
> ~Aaron
>
> On Mon, Oct 14, 2024 at 4: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
>