https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nshead at gcc dot gnu.org
--- Comment #7 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
I no longer get the "error: 'goto' is not a constant expression" error in
comment #0 (or in the linked dup) for GCC 16. However, in C++17 mode I still
get the unhelpful "not usable as a 'constexpr' function because:" (no further
context).
Taking a look, the root issue is that some checks are done during parsing,
which typically complain and then set 'cp_function_chain->invalid_constexpr =
true;'. However, merely instantiating a constexpr template does not produce
these errors, but do still mark it as invalid; later,
'explain_invalid_constexpr_fn' sees that the function was invalid but none of
the checks it performs catch these issues. There are a number of cases where
this occurs; it's especially easy to see this with lambdas, e.g. for pre-c++23,
the following invalid code:
auto l = []{
if (false)
thread_local int x;
return 123;
};
constexpr int r = l();
no longer walks and finds the thread_local declaration of 'x', and so gives no
proper explanation for the error.
I think all uses of 'invalid_constexpr' that I could find are suspect for this
issue and will need adjustment to ensure that 'explain_invalid_constexpr_fn'
can properly retrieve the actual error. Maybe the best approach would be to
store away the error message somewhere and replay it somehow, rather than
needing to reimplement the parse-time analysis specifically for e_i_c_f (which
is likely to get bitrotten as updates continue to be made).
