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

Reply via email to