Shafik Yaghmour

Sounds like this can be closed, right?

I was going to say the problem in `findSubobject(...)` is the type of `Index` is ```cpp uint64_t Index = Sub.Entries[I].getAsArrayIndex(); ``` but the signature of `expandArray(...)` takes `unsigned` ```cpp static...

So in `HandleOperatorNewCall(...)` we get here: ```cpp QualType AllocType = Info.Ctx.getConstantArrayType(ElemType, Size, nullptr, ArrayType::Normal, 0); APValue *Val = Info.createHeapAlloc(E, AllocType, Result); *Val = APValue(APValue::UninitArray(), 0, Size.getZExtValue()); Result.addArray(Info, E, cast(AllocType)); ```...

Later on when we are in `findCompleteObject(...)` we end up here: ```cpp } else if (DynamicAllocLValue DA = LVal.Base.dyn_cast()) { std::optional Alloc = Info.lookupDynamicAlloc(DA); if (!Alloc) { Info.FFDiag(E, diag::note_constexpr_access_deleted_object) Value,...

I think it might be useful to diagnose these limitation for the time being and perhaps link to this discussion in a FIXME. I don't see a quick fix here...

The topic of step limits came up and this bug seems to be show some inconsistency with how we handle limits in some cases: https://github.com/llvm/llvm-project/issues/49064#issuecomment-1636608426 maybe worth digging into more.

I don't see a workaround, it looks out of date at this point. Someone needs to remove the `CheckForMissingFields = false;` but this is a potentially breaking change since there...

@AaronBallman sounds like missing this case is not ideal, wdyt about making this change?

So we are hitting [dcl.init.aggr p5.2](https://eel.is/c++draft/dcl.init.aggr#5.2): > Otherwise, if the element is not a reference, the element is copy-initialized from an empty initializer list ([dcl.init.list]). and if we try another...

Note there are several discussions in the review: http://108.170.204.19/D157879 notably: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868 CC @Fznamznon @AaronBallman