On Mon, 16 Feb 2026 at 09:08, Jason Merrill <[email protected]> wrote:
>
> On 2/12/26 5:02 PM, Jakub Jelinek wrote:
> > On Thu, Feb 12, 2026 at 01:48:59PM +0900, Jason Merrill wrote:
> >>> --- gcc/cp/constexpr.cc.jj 2026-02-09 09:06:41.657345262 +0100
> >>> +++ gcc/cp/constexpr.cc 2026-02-10 13:09:30.059258053 +0100
> >>> @@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.
> >>> #include "intl.h"
> >>> #include "toplev.h"
> >>> #include "contracts.h"
> >>> +#include "c-family/c-pragma.h"
> >>
> >> Is this still needed for this version?
> >
> > It is new in this version, so that parse_in can be used when translating
> > the messages back from exec charset/UTF-8 to SOURCE_CHARSET.
> > If it is moved to semantics.cc through overload with constexpr_ctx, I guess
> > it will not be needed.
> >
> >>> static bool verify_constant (tree, bool, bool *, bool *);
> >>> #define VERIFY_CONSTANT(X)
> >>> \
> >>> @@ -2314,6 +2315,295 @@ cxx_eval_cxa_builtin_fn (const constexpr
> >>> }
> >>> }
> >>> +/* Attempt to evaluate T which represents a call to
> >>> __builtin_constexpr_diag.
> >>> + The arguments should be an integer (0 for inform, 1 for warning, 2 for
> >>> + error) and 2 messages which are either a pointer to a STRING_CST or
> >>> + class with data () and size () member functions like string_view or
> >>> + u8string_view. */
> >>
> >> Please explain the significance of the two messages as well. And also the
> >> expected types.
> >
> > Will do.
> >
> >> Why is the tag string before the message string, since the tag is the one
> >> that's sometimes omitted?
> >
> > Tag comes first because that is what P2758R5 says in its API, the builtin
> > attempts to match those (except that it has an extra first argument which
> > differentiates error/warning/print).
> >>>> + /* Can't use cstr.extract because it evaluates the
> >>> + arguments in separate constexpr contexts. */
> >>
> >> Didn't I already suggest adding another overload that takes a
> >> constexpr_ctx?
> >> This is too much code to duplicate in a user.
> >
> > Will do.
> >
> >>> + constexpr void constexpr_print_str(string_view __msg) noexcept
> >>> + { return __builtin_constexpr_diag(0, "", __msg); }
> >>> // { dg-message "constexpr message: foo" }
> >>
> >> Hmm, it would be more useful if the messages were at the call site of this
> >> function rather than at the definition. I guess you can get that location
> >> from call_stack. But this can be a followup.
> >
> > Well, it really depends on whether one uses the builtin directly (when
> > the thing is not standardized yet, perhaps Jonathan will not want to
> > add the standard APIs in libstdc++ just yet) or through wrappers like
> > that.
>
> What do you think, Jonathan?
I don't think we want the proposed std::constexpr_xxx_str names yet.
We could add them using reserved names like __constexpr_print_str, but
I was assuming that for now people could just use the builtin directly
instead of some other non-standard name.
If using the builtin directly gives better location info, then that is
another argument in favour of not adding wrappers yet.
>
> > One option would be figure the location_t of caller vs. of caller's caller
> > through checking if the caller is std::constexpr_{print,warning,error}_str,
> > another would be to say or in magic constant (say 16) into the first
> > argument if it wants caller's caller location_t.
>
> I guess the second would be simpler.
>
> Jason
>
