On Tue, 15 Jul 2025 at 13:55, Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Tue, Jul 15, 2025 at 08:30:33AM -0400, Jason Merrill wrote:
> > > The diagnostic only changed for C++26, and I'm not sure why (the _S_at
> > > function isn't constexpr, so why wasn't it failing there before?)
> >
> > In C++23, we could see that the outermost thing in the expression is a call
> > to _M_error, and it's non-constexpr, so we give up at that point and never
> > look at the call to _S_at.
>
> Yeah.  Though, even in GNU++23 we could have
>   foo (({ if (x == 42) return 14; 23; }), 12);
> with non-constexpr foo, so maybe we could do that regardless of the C++ level.
> We've never handled that before during constant evaluation though and now
> handle it at least in some (for C++26 hopefully most or all) cases, say
>   ({ if (x == 42) return 14; 23 }) + x
> etc.
>
> > In C++26, evaluating the arguments to a function (including the object
> > argument) might throw before we get to calling the non-constexpr function,
> > so we need to evaluate them before giving up.
>
> There can be other reasons for different diagnostics between C++23 and C++26
> related to the constexpr exceptions patch, e.g.
> potential_constant_expression for C++26 can let some expressions through
> as potentially constant because it has to assume some call could throw,
> while in C++23 and earlier that would be impossible, and so something can be
> diagnosed only later for C++26.


OK, thank you both, I'm happy to just tweak the dg-error patterns now then.

Reply via email to