I am working on updating a large codebase to C++20 and we keep hitting variations of this bug - 53773. The last issue being https://godbolt.org/z/n83sbGbs3. Would anyone have any pointers on what would a fix be?
1 Like
The issue is still being discussed, so it’s a bit hard to say exactly what the correct fix is yet. However, I can at least say that most of the constant expression evaluation happens in https://github.com/llvm/llvm-project/blob/main/clang/lib/AST/ExprConstant.cpp – you could start by seeing what the call path is to get to the diagnostic causing the constexpr failure to determine why we’re constant evaluating that code (I mentioned my thoughts on the issue but I don’t have the chance to track it down myself).
I have the sneaking suspicion the fix here is to implement Relaxing some constexpr restrictions
I did a little looking into this at one point, and we do much of this work in SemaExpr.cpp ~18035. We determine that it is “NeededForConstantEvaluation” under C++20’s expr.const p12, which means we need the definition based on a handful of references, of which C++11 temp.inst p3 and C++20 temp.inst p7 seem relevant.
It was pointed out that CWG 1581 might be related: C++ Standard Core Language Defect Reports and Accepted Issues
1 Like
In the thread at
https://discourse.llvm.org/t/point-of-instantiation-of-constexpr-function-template/65129
we tracked this down to
https://github.com/llvm/llvm-project/commit/242ad89a15d5466d166d47978bfff983d40ab511
“C++11 half of r147023: In C++11, additionally eagerly instantiate:” and
its “Do not defer instantiations of constexpr functions” comment in
(back then) Sema::MarkDeclarationReferenced.