At the moment we are unable to handle ArrayInitLoopExpr if the array it initializes is an array of non-POD types.
The expression is supposed to create a new array, and invoke the copy constructor for each element. The CFG only
contains the copy constructor, which is supposed to be invoked for each corresponding element, however it doesn't
contain the index of each element or a construction context.
The idea is to add a construction context to the copy ctor, so that after we evaluate it, the elements are placed in the
proper region of the store. Besides that in handleConstructor, we manually select which element of the array is going
to be passed to the ctor as parameter. Everything else is the same as it happens with a simple non-POD array construction,
in another patch, which this one depends on.
Depends on: https://reviews.llvm.org/D127973
This tiny piece of code currently mimics/duplicates ExprEngine::VisitLambdaExpr.
I'm not sure if that tiny piece of code represents the correct solution in general, I suspect that eg. if lambda is put into a variable then it needs to be constructed directly in the variable, through copy elision (?) So eventually we'll probably need to assign a construction context to LambdaExpr itself, and then use both of them here, maybe recursively. But this is what we have for now.
So for this patch, I think the right thing to do is to have ExprEngine::VisitLambdaExpr() lookup the region created here instead, from objects-under-construction. This way future improvements could be done in one place, and the infrastructure will already be there.