Hi,
On 22/03/2018 22:19, Jason Merrill wrote:
On Thu, Mar 22, 2018 at 3:35 PM, Paolo Carlini <paolo.carl...@oracle.com> wrote:
Hi again,
On 22/03/2018 19:58, Paolo Carlini wrote:
Nice. While I start implementing the above, any hint about thing like
g++.dg/cpp0x/initlist68.C, which we would reject because involves a plain
constructor of type ARRAY_TYPE, not a proper BRACE_ENCLOSED_INITIALIZER_P?
Also, less important I guess, we would also reject g++.dg/torture/pr70499.C
to which you added -fpermissive in the occasion of c++/78345. Or maybe you
meant something a bit less drastic ;)
I suspect that allowing for either BRACE_ENCLOSED_INITIALIZER_P or
CONSTRUCTOR with a check of the type (like you changed build_vec_init at the
time:
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/init.c?r1=246244&r2=246243&pathrev=246244
) would work fine.
Yes, that sounds good. And if pr70499.C fails, let's fix the testcase
to add the missing braces.
Ok about pr70499.C.
Unfortunately, however, the above idea still is not enough: for, say,
lambda-array.C we have to accept as init an INDIRECT_REF with
ARRAY_TYPE, thus qualified CONSTRUCTOR isn't enough, it really looks
like we have to accept various (?) TREE_CODEs with ARRAY_TYPE as type,
not just CONSTRUCTORs, to handle normal well formed code. Thus my best
try so far would be the below, in testing. What do you think?
Cheers,
Paolo.
/////////////////////
