OK.
Jason
... concretely, I tested successfully the below.
Thanks,
Paolo.
Index: cp/parser.c
===
--- cp/parser.c (revision 227737)
+++ cp/parser.c (working copy)
@@ -7591,8 +7591,9 @@ cp_parser_new_expression (cp_parser*
On 11 September 2015 at 23:05, Jason Merrill wrote:
> Hmm, I think we really ought to accept
>
> new auto { 2 }
>
> to be consistent with all the other recent changes to treat { elt } like
> (elt); this seems like a piece that was missed from DR 1467. Do you agree,
> Ville?
Yes. I thought we
Hi,
On 09/11/2015 10:05 PM, Jason Merrill wrote:
On 09/11/2015 03:11 PM, Paolo Carlini wrote:
this is a slightly reworked (simplified) version of a patch I sent a
while ago. The issue is that we are not enforcing at all 5.3.4/2 in the
parser, thus we end up rejecting the first test below with a
On 09/11/2015 03:11 PM, Paolo Carlini wrote:
this is a slightly reworked (simplified) version of a patch I sent a
while ago. The issue is that we are not enforcing at all 5.3.4/2 in the
parser, thus we end up rejecting the first test below with a misleading
error message talking about list-initia
Hi,
this is a slightly reworked (simplified) version of a patch I sent a
while ago. The issue is that we are not enforcing at all 5.3.4/2 in the
parser, thus we end up rejecting the first test below with a misleading
error message talking about list-initialization (and a wrong location),
beca
Hi,
the below implements quite literally the requirements. It does that
after the cp_parser_new_initializer call, I think that makes in general
for better error recovery. The wording definitely needs a review, though
(more concise?). Tested x86_64-linux.
Thanks,
Paolo.
/
