tbaeder added a comment. If you apply e.g.
@@ -10739,6 +10779,7 @@ bool ArrayExprEvaluator::VisitInitListExpr(const InitListExpr *E, << NumEltsToInit << ".\n"); Result = APValue(APValue::UninitArray(), NumEltsToInit, NumElts); + llvm::errs() << "Result " << &Result << ": " << Result.isArray() << "\n"; // If the array was previously zero-initialized, preserve the // zero-initialized values. @@ -10764,6 +10805,7 @@ bool ArrayExprEvaluator::VisitInitListExpr(const InitListExpr *E, } } + llvm::errs() << "Result " << &Result << ": " << Result.isArray() << "\n"; if (!Result.hasArrayFiller()) return Success; and run the test case, the first added line prints `1` and the second one `0`. `Result` is being mutated when doing the in-place evaluation. > I take that to mean that the expectation for this interface is that the > caller validates the APValue in the cases where it doesn't already know the > answer. Sure, that was the other option. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128248/new/ https://reviews.llvm.org/D128248 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits