When I was prototyping it in clang, I was trying different approaches, and personally liked the most some sort of prefix like -Wconstexpr:<userdefinedtag> so user code can't create warning/error which would use compiler's own tag. Plus if this will ever get into the standard, there shouldn't not be any prefix in the tag as different compilers can have different CLI options or even interface to enable / disable tag.
More I think about it ... the tag shouldn't be a string but a type, and tag then can be fully qualified name, that would set clear ownership of errors / warnings to libraries. Hana > On 13. 11. 2025, at 21:46, Jakub Jelinek <[email protected]> wrote: > > On Thu, Nov 13, 2025 at 12:30:42PM +0000, Jonathan Wakely wrote: >>> Here is a slightly updated version of the patch. >>> Fixes the mce_unknown case (sets *non_constant_p in that >>> case so that we e.g. don't try to cache results without emitting >>> diagnostics), the previous patch was incorrect in that part >>> and returned the CALL_EXPR instead of void_node while not setting >>> *non_constant_p. >>> Doesn't implicitly add W in front of the tag when looking it up, >>> I think it is better when people write "Wuninitialized" rather than >>> just "uninitialized". >>> Emits the tag whenever it is non-empty and warning doesn't emit it, >>> in similar style/color to the warning [-Woption] strings. >>> And adds testsuite coverage. >>> >>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >>> >>> Note, haven't added user documentation for this because it might change >>> behavior before C++29 gets something voted in, or perhaps have >>> the custom tags support added or whatever. >> >> I would be very happy to see this in GCC 16. The ability to "debug" >> constexpr functions is long overdue. >> >> I don't love the inconsistency of having '-' in [-Wfoo] for a tag >> "Wfoo" only when issuing a warning, but not an error or a message ... >> but I understand that comes from the existing diagnostic machinery. >> But I don't really know how the tags should map to command-line >> options at all. We'll probably need to iterate on that as we get user >> feedback. > > I'm open to suggestions. I think the user should be able to differentiate > between tags which are supported warning options (and thus actually can > as in the patch turn the constexpr_warning_str on or off) from unsupported > tags > which currently aren't controllable. Right now in the patch the > difference is in the missing - after [ for non-supported tag and no URL > underline). > Whether there should be some new option like -Wconstexpr-msg=<tag> where > one could control these one by one (and how hard would it be to > #pragma GCC diagnostic ignored "-Wconstexpr-msg=foobar" > ) is one, thing, whether supported tags should influence also the > print case (if the warning is disabled, don't print anything, otherwise > inform), whether supported tags should influence some way the error > case is another question (should it error if say using "Wuninitialized" > tag and the warning isn't explicitly enabled? Should it only not > error if explicitly -Wno-uninitialized? Stuff like that). > And if there is -Wconstexpr-msg=foobar option, shall we ask users > to use "Wconstexpr-msg=foobar" tags or "foobar" ? > > Jakub >
