[AST][RecoveryExpr] Populate the dependence bits from CompoundStmt result expr to StmtExpr.

[hokein]

Summary

We lost errorBit for StmtExpr if a recoveryExpr is the result
expr of a CompoundStmt, which will lead to crashes.

// `-StmtExpr
//   `-CompoundStmt
//     `-RecoveryExp
({ invalid(); });

[sammccall]

clang/lib/AST/ComputeDependence.cpp

130–131

I think I know the answer now - you can't expand a param pack over stmtexpr boundaries. Could repace this comment...

130–131

I wonder if this is still needed - how can we get a type for the stmtexpr unless we have a result expr providing the type?

137

Nit: i'd probably leave this as the last clause as it's the weird edge case.

143

Maybe just "propagate dependence of the result"? The compound statement seems like a red herring.

148

this should avoid propagating the pack bit as above (or factor it out and mask it off at the end to avoid writing it twice)

[hokein]

address comments.

clang/lib/AST/ComputeDependence.cpp

130–131

it is possible that the stmtexpr has a type and doesn't have a result expr, e.g ({ if (1) {}; }), the default type is void.

clang/lib/AST/ComputeDependence.cpp

ExprDependence clang::computeDependence(ConditionalOperator *E) {
   return E->getCond()->getDependence() | E->getLHS()->getDependence() |
          E->getRHS()->getDependence();
 }
 
 ExprDependence clang::computeDependence(BinaryConditionalOperator *E) {
   return E->getCommon()->getDependence() | E->getFalseExpr()->getDependence();
 }
 
 ExprDependence clang::computeDependence(StmtExpr *E, unsigned TemplateDepth) {
-  // FIXME: why is unexpanded-pack not propagated?
-  auto D = toExprDependence(E->getType()->getDependence()) &
-           ~ExprDependence::UnexpandedPack;
+  auto D = toExprDependence(E->getType()->getDependence());
+  // Propagate dependence of the result.
+  if (const auto *CompoundExprResult =
+          dyn_cast_or_null<ValueStmt>(E->getSubStmt()->getStmtExprResult()))
+    if (const Expr *ResultExpr = CompoundExprResult->getExprStmt())
+      D |= ResultExpr->getDependence();
   // Note: we treat a statement-expression in a dependent context as always
   // being value- and instantiation-dependent. This matches the behavior of
   // lambda-expressions and GCC.
   if (TemplateDepth)
     D |= ExprDependence::ValueInstantiation;
-  return D;
+  // A param pack cannot be expanded over stmtexpr boundaries.
+  return D & ~ExprDependence::UnexpandedPack;
 }
 
 ExprDependence clang::computeDependence(ConvertVectorExpr *E) {
   auto D = toExprDependence(E->getType()->getDependence()) |
            E->getSrcExpr()->getDependence();
   if (!E->getType()->isDependentType())
     D &= ~ExprDependence::Type;
   return D;
 }
 
 ExprDependence clang::computeDependence(ChooseExpr *E) {
   if (E->isConditionDependent())
     return ExprDependence::TypeValueInstantiation |

clang/test/SemaCXX/invalid-constructor-init.cpp

 // RUN: %clang_cc1 -frecovery-ast -verify %s
 
 struct X {
   int Y;
   constexpr X() // expected-error {{constexpr constructor never produces}}
       : Y(foo()) {} // expected-error {{use of undeclared identifier 'foo'}}
 };
 // no crash on evaluating the constexpr ctor.
 constexpr int Z = X().Y; // expected-error {{constexpr variable 'Z' must be initialized by a constant expression}}
 
 struct X2 {
   int Y = foo();    // expected-error {{use of undeclared identifier 'foo'}} \
                  // expected-note {{subexpression not valid in a constant expression}}
   constexpr X2() {} // expected-error {{constexpr constructor never produces a constant expression}}
 };
 
+struct X3 {
+  int Y;
+  constexpr X3() // expected-error {{constexpr constructor never produces}}
+      : Y(({foo();})) {} // expected-error {{use of undeclared identifier 'foo'}}
+};
+
 struct CycleDelegate {
   int Y;
   CycleDelegate(int)
       : Y(foo()) {} // expected-error {{use of undeclared identifier 'foo'}}
   // no bogus "delegation cycle" diagnostic
   CycleDelegate(float) : CycleDelegate(1) {}
 };