[clang] [clang][CodeGen] Fix assertion failure with #embed in array new-expression initializers (PR #218262)

[Akash Manna via cfe-commits]

================
@@ -1138,24 +1139,44 @@ void CodeGenFunction::EmitNewArrayInitializer(
 
     CharUnits StartAlign = CurPtr.getAlignment();
     unsigned i = 0;
+    auto AdvanceToNextElement = [&]() {
+      CurPtr = Address(Builder.CreateInBoundsGEP(CurPtr.getElementType(),
+                                                 CurPtr.emitRawPointer(*this),
+                                                 Builder.getSize(1),
+                                                 "array.exp.next"),
+                       CurPtr.getElementType(),
+                       StartAlign.alignmentAtOffset((++i) * ElementSize));
+    };
     for (const Expr *IE : InitExprs) {
       // Tell the cleanup that it needs to destroy up to this
       // element.  TODO: some of these stores can be trivially
       // observed to be unnecessary.
       if (EndOfInit.isValid()) {
         Builder.CreateStore(CurPtr.emitRawPointer(*this), EndOfInit);
       }
+      // An EmbedExpr can initialize more than one array element.
+      const auto *EmbedS = dyn_cast<EmbedExpr>(IE->IgnoreParenImpCasts());
+      if (EmbedS && EmbedS->getDataElementCount() > 1) {
----------------
akash-manna-sky wrote:

Sorry for the confusion — since `_Complex` isn't integer/floating, `HandleEmbed` never takes the multi-element path for it, so f13's `limit(2)` embed is sliced by Sema into two *single-element* `EmbedExpr`s, each wrapped in `IntegralRealToComplex`. Those are what reach this loop: without the count check they take this branch and `EmitScalarConversion` asserts on the complex destination (the crash this check originally fixed); with it they go through `StoreAnyExprIntoOneUnit`, where the cast does the conversion.

Agreed it would be cleaner if Sema didn't create single-element `EmbedExpr`s at all — but it does today for sliced embeds (the `EE(3rd element)` example in `Expr.h`), so that looks like the representation cleanup Eli suggested doing separately; with it this check can go away. Should I add an explicit `limit(1)` complex test and a clarifying comment here if you'd like? 


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