[clang] [clang][CompundLiteralExpr] Don't defer evaluation for CLEs (PR #137163)

[kadir çetinkaya via cfe-commits]

================
@@ -9125,9 +9126,25 @@ bool
 LValueExprEvaluator::VisitCompoundLiteralExpr(const CompoundLiteralExpr *E) {
   assert((!Info.getLangOpts().CPlusPlus || E->isFileScope()) &&
          "lvalue compound literal in c++?");
-  // Defer visiting the literal until the lvalue-to-rvalue conversion. We can
-  // only see this when folding in C, so there's no standard to follow here.
-  return Success(E);
+  APValue *Lit;
+  // If CompountLiteral has static storage, its value can be used outside
+  // this expression. So evaluate it once and store it in ASTContext.
+  if (E->hasStaticStorage()) {
+    Lit = E->getOrCreateStaticValue(Info.Ctx);
+    Result.set(E);
+    // Reset any previously evaluated state, otherwise evaluation below might
+    // fail.
+    // FIXME: Should we just re-use the previously evaluated value instead?
+    *Lit = APValue();
----------------
kadircet wrote:

sorry for the late response here, it took me a while to wrap my head around it and then I got interrupted :(

> Roughly, the issue is that, if you constant-evaluate the expression in isolation, you get a different result from what you'd get evaluating the whole expression. So we can't redo the evaluation in ConstantFold mode: if you do, you'll corrupt the precomputed value

I am not sure if this applies to CLEs and even if it does I don't think this patch is making it worse:
- CLEs can only have constant expressions as initializers, as you also highlighted above. Hence (i think) evaluating them multiple times or evaluating sub-parts of them shouldn't matter.
- As things stand clang is already evaluating CLEs from scratch every time it needs to (so if there's a problem here, it already exists).

 > I think compound literals run into similar issues if you allow ConstantFold mode to overwrite the evaluated value.

Sorry if I am being dense, but there's a good chance I didn't fully understand your point. So if you think what I said above doesn't make sense, I'd really appreciate if you can provide a code snippet that demonstrates such a case?

https://github.com/llvm/llvm-project/pull/137163