https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115844
--- Comment #2 from Ali Mohammad Pur Fard <ali.mpfard at gmail dot com> --- > clang gives the same error message Then perhaps their diagnostic is also not the best. > See https://wg21.link/p2564 >From my interpretation of their given rules, this lambda should not qualify: - If a constexpr function contains a call to an immediate function outside of an immediate function context, and that call itself isn’t a constant expression, said constexpr function implicitly becomes a consteval function. This is intended to include lambdas, function template specializations, special member functions, and should cover member initializers as well. The lambda is not constexpr, nor can it ever be constexpr (due to the capture). - If an expression-id designates a consteval function without it being an immediate call in such a context, it also makes the context implicitly consteval. Such expression-id’s are also allowed in contexts that are manifestly constant evaluated. The expression is a call to a consteval function, making it an immediate call (albeit invalid). - Other manifestly constant evaluated contexts (like constant-expression and the condition of a constexpr if statement) are now considered to be immediate function contexts. N/A. Either way, I'm not interested in arguing about the interpretation, rather that the diagnostics are completely useless ("you came up with a reason to make this consteval, and now you're telling me it's not - of course it's not"), and unhelpful (as they do not mention the call to a non-consteval function in a consteval context, which is practically never valid); especially when calling a non-consteval forward-declared function is just about the only way to fail compilation from inside a consteval context (though I suspect _any_ failure will cause the actual failure cause to be omitted and replaced with this)
