On 1/7/19 10:38 AM, Bernd Edlinger wrote:
On 1/7/19 1:08 AM, Martin Sebor wrote:
On 1/5/19 9:04 AM, Bernd Edlinger wrote:
On 1/4/19 10:22 PM, Jason Merrill wrote:
Hmm, I'm uncomfortable with starting to pass in the decl just for the sake of
deciding whether this diagnostic should be a pedwarn or error. In general,
because of copy elision, we can't know at this point what we're initializing,
so I'd rather not pretend we can. Instead, maybe add a
LOOKUP_ALLOW_FLEXARY_INIT flag that you can add to the flags argument in the
call from store_init_value?
Okay, I reworked the patch, to pass a bit in the flags, it was a bit more
complicated
than anticipated, because it is necessary to pass the flag thru
process_init_constructor
and friends to the recursive invocation of digest_init_r. It turned out that
digest_nsdmi_init did not need to change, since it is always wrong to use
flexarray init
there. I added a new test case (flexary32.C) to exercises a few cases where
non static
direct member intializers are allowed to use flexarrays (in static members) and
where that
would be wrong (in automatic members). So that seems to work.
If that resolves pr69338 can you please also reference the bug in
the test and in the ChangeLog? (Ditto for pr69697.)
Yes, those appear to be fixed as well.
Added pr69338 + pr69697 to the ChangeLog,
and also added test cases from both PRs.
Attached the otherwise unchanged v3 of my patch.
Is to OK for trunk?
OK, thanks.
Jason
