Date: Mon, 14 Oct 2024 15:05:12 -0500
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
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
Received on 2024-10-14 20:05:26