regevran wrote:
> I think the array initialization has a bug; if that's a real pain to address
> as part of this PR, I think this is still fine as-is because it's forward
> progress in a lot of ways. But if it can be addressed within this PR, that
> would be nice. WDYT?
With the help of AI I constructed three different cases that all get
ArrayInitLoopExpr node in the AST, only Case 1 belong to this PR:
```cpp
// Case 1: structured-binding array decomposition
void f() {
int arr[3] = {1, 2, 3};
auto [a, b, c] = arr;
}
// -ast-dump: ArrayInitLoopExpr 'int[3]'
// `-OpaqueValueExpr -> DeclRefExpr 'arr'
// Case 2: lambda capturing an array by value
struct NonTrivial { NonTrivial(); NonTrivial(const NonTrivial&); };
void f() {
NonTrivial arr[3];
[arr] { (void)arr; };
}
// -ast-dump: ArrayInitLoopExpr 'NonTrivial[3]'
// `-OpaqueValueExpr -> DeclRefExpr 'arr'
// Case 3: implicit copy constructor initializing an array member
struct Holder { NonTrivial arr[3]; };
void f(Holder& h) {
Holder h2 = h; // invokes the implicit copy constructor
}
// -ast-dump: CXXCtorInitializer Field 'arr'
// -ArrayInitLoopExpr 'NonTrivial[3]' //
-OpaqueValueExpr -> MemberExpr .arr
```
Note: Case 2 and Case 3 do NOT get into `StmtPrinter::VisitArrayInitLoopExpr`
from their own personal reasons, only structured-binding array decomposition
does.
However, fixing the general case and verifying `getSourceExpr()` is safe to
rely on in every case that reaches `StmtPrinter::VisitArrayInitLoopExpr` (not
just these three) is beyond this PR, IMHO.
https://github.com/llvm/llvm-project/pull/221711
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
