On Wed, Nov 16, 2022 at 09:33:27AM -0500, Jason Merrill wrote:
> > and at that point I fear decl_maybe_constant_var_p will not work
> > properly. Shall this hunk be moved somewhere else (cp_finish_decl?)
> > where we can already call it, or do the above in start_decl for
> > cxx_dialect < cxx20 and add a cxx_dialect == cxx20 hunk in cp_finish_decl?
>
> Hmm, I'd expect decl_maybe_constant_var_p to work fine at this point.
For static constexpr vars sure, but what about
static const where start_decl doesn't know the initializer?
Sure, decl_maybe_constant_var_p will not crash in that case, but
it will return true even if the static const var doesn't have
a constant initializer. Sure, we'd catch that later on when actually
trying to constexpr evaluate the function and hitting there the
spots added for C++23 in potential_constant_expression*/cxx_eval_*,
but it would mean that we don't reject it when nothing calls the functions.
I meant something like:
constexpr int bar (int x) { if (x) throw 1; return 0; }
constexpr int foo () { static const int a = bar (1); return 0; }
with -std=c++20 IMHO shouldn't be accepted, while in C++23 it should.
With
constexpr int a = foo ();
added we reject it in C++23 (correct), but the diagnostics is too weird:
test.C:3:23: in ‘constexpr’ expansion of ‘foo()’
test.C:3:24: error: ‘__atomic_load_1((& _ZGVZ3foovE1a), 2)’ is not a constant
expression
3 | constexpr int a = foo ();
| ^
Jakub
