OK, thanks.
Jason
Hi,
On 12/23/2014 07:13 PM, Jason Merrill wrote:
On 12/23/2014 11:30 AM, Paolo Carlini wrote:
if (maybe_range_for_decl)
-*maybe_range_for_decl = error_mark_node;
+{
+ *maybe_range_for_decl = error_mark_node;
+ if (*equal_loc == UNKNOWN_LOCATION)
+tmp_equal_loc
On 12/23/2014 11:30 AM, Paolo Carlini wrote:
if (maybe_range_for_decl)
- *maybe_range_for_decl = error_mark_node;
+ {
+ *maybe_range_for_decl = error_mark_node;
+ if (*equal_loc == UNKNOWN_LOCATION)
+ tmp_equal_loc = token->location;
Even though the
Hi again,
thus, in order to deal with the various subissues we have got, I
prepared the below, which passes testing. As you can see, the diagnostic
triggers only once, for the left-most '=' and/or the left-most ','. I
suppose that's Ok, I'm not 100% sure about the wording of the error
message
.. and, to make things more interesting ;) for:
for (int a, b, c: arr)
we currently give:
63985.C:7:19: error: expected initializer before β:β token
63985.C:7:21: warning: range-based βforβ loops only available with
-std=c++11 or -std=gnu++11
because, inside cp_parse_init_declarator we ar
On 12/22/2014 04:51 PM, Paolo Carlini wrote:
Well, if they are both right, could we maybe do something closer to
clang, instead, thus not consider the for loop a range-based for loop
only because after the initializer there is a colon when the decl is
error_mark_node?
I think we want to tell th
Hi,
On 12/22/2014 10:12 PM, Jason Merrill wrote:
We could also peek for a colon in cp_parser_init_declarator after
parsing the initializer, and give an error then.
I see.
For
the record, clang vs edg appear to handle this case differently: clang
considers it a wrong for loop, edg a wrong range
On 12/22/2014 03:11 PM, Paolo Carlini wrote:
That would be the place. But, at that point, it could still be a normal
for loop, thus we can't just give an error.
Ah, yes.
Assigning error_mark_node on
the other hand is correct, because later, if we find the colon, we
realize that the declaratio
Hi,
On 12/22/2014 07:55 PM, Jason Merrill wrote:
On 12/04/2014 07:51 AM, Paolo Carlini wrote:
Ideally, it would be nice to say something
more detailed about the invalid declaration, but that doesn't seem
trivial...
How about giving that error in cp_parser_init_declarator?
/* An `=' or an
On 12/04/2014 07:51 AM, Paolo Carlini wrote:
Ideally, it would be nice to say something
more detailed about the invalid declaration, but that doesn't seem
trivial...
How about giving that error in cp_parser_init_declarator?
/* An `=' or an `(', or an '{' in C++0x, indicates an initializer.
Hi,
On 12/04/2014 01:54 PM, Paolo Carlini wrote:
... oops, sent the wrong patch. See the below instead.
Paolo.
It occurs to me that a while ago I sent this patch: what do you think?
Is the diagnostic good enough?
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00376.html
https://gcc.gn
... oops, sent the wrong patch. See the below instead.
Paolo.
///
Index: cp/parser.c
===
--- cp/parser.c (revision 218348)
+++ cp/parser.c (working copy)
@@ -10841,6 +10841,7 @@ cp_parser_for_init_statement (cp_parse
Hi,
this accepts-invalid is about an invalid loop of the form:
for (int i = 5: arr)
thus it starts with an initialized declaration, which would be legal in
a normal for loop, but then the colon means that it can only be an
invalid range-based for loop. Ideally, it would be nice to say som
13 matches
Mail list logo