Aggregate parens-init checks for dangling too aggressively

[timsong-cpp]

Clang rejects the well-formed but dangling cases from http://eel.is/c++draft/dcl.init.general#example-3:

struct A {
  int a;
  int&& r;
};

int f();
int n = 10;

A a2(1, f());                   // well-formed, but dangling reference
A a4(1.0, 1);                   // well-formed, but dangling reference

<source>:9:9: error: reference member 'r' binds to a temporary object whose lifetime would be shorter than the lifetime of the constructed object
A a2(1, f());                   // well-formed, but dangling reference
        ^~~
<source>:3:9: note: reference member declared here
  int&& r;
        ^
<source>:10:11: error: reference member 'r' binds to a temporary object whose lifetime would be shorter than the lifetime of the constructed object
A a4(1.0, 1);                   // well-formed, but dangling reference
          ^
<source>:3:9: note: reference member declared here
  int&& r;

Now, these particular examples may well have justified a warning, but Clang also rejects

void f(A);

void g() {
    f(A(1, 1));
}

in which both the temporary and the aggregate live to the end of the full-expression. It also warns on

void h(int i) {
   f(A(1, static_cast<int&&>(i)));
}

<source>:16:31: warning: binding reference member 'r' to stack allocated parameter 'i' [-Wdangling-field]
    f(A(1, static_cast<int&&>(i)));
                              ^
<source>:3:9: note: reference member declared here
  int&& r;
        ^

even though i outlives the aggregate.

This will affect uses of C++23 std::ranges::elements_of, which is an aggregate with a reference member that is intended to be used exactly like this.

[shafik]

@alanzhao1 @zygoloid I think this is more fallout from #61145 please confirm

[alanzhao1]

I think this has a different root cause than #61145

The root cause of #61145 is that certain parts of the AST weren't being carried over during a TreeTransform, but there's no TreeTransform going on in this bug.

[zygoloid]

Yeah, I suspect the problem in this case is that we're incorrectly reusing the rules that we use in a constructor's mem-initializer-list (in which context this kind of initialization is ill-formed) here. We probably need a new kind of InitializedElement so we can distinguish these cases.

[llvmbot]

@llvm/issue-subscribers-c-20

[alanzhao1]

Candidate patch: https://reviews.llvm.org/D148274

[alanzhao1]

@shafik any thoughts on backporting this into 16.0.x?

[alanzhao1]

Reopening for backporting per discussion in https://reviews.llvm.org/D150122

I'll wait for #62266 to be backported before working on this fix as otherwise there'll be a merge issue.