================
@@ -2411,10 +2411,15 @@ static bool
CheckEvaluationResult(CheckEvaluationResultKind CERK,
const FieldDecl *SubobjectDecl,
CheckedTemporaries &CheckedTemps) {
if (!Value.hasValue()) {
- assert(SubobjectDecl && "SubobjectDecl shall be non-null");
- Info.FFDiag(DiagLoc, diag::note_constexpr_uninitialized) << SubobjectDecl;
- Info.Note(SubobjectDecl->getLocation(),
- diag::note_constexpr_subobject_declared_here);
+ if (SubobjectDecl) {
+ Info.FFDiag(DiagLoc, diag::note_constexpr_uninitialized)
+ << true << SubobjectDecl;
+ Info.Note(SubobjectDecl->getLocation(),
+ diag::note_constexpr_subobject_declared_here);
+ } else {
+ // FIXME: We should add a test to check the output of this case.
+ Info.FFDiag(DiagLoc, diag::note_constexpr_uninitialized) << false <<
Type;
----------------
hazohelet wrote:
Finally I found a test case that can check the fallback diagnostic message:
https://godbolt.org/z/Mc3nPq15n
Clang 16's output is a little weird in that it does not mention `new
*char[3][1]` part, and this patch's fallback approach inherits this behavior.
https://github.com/llvm/llvm-project/pull/67817
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
