* [C PATCH] Fix parsing when using declarations in for loops and typedefs (PR c/67784)
@ 2015-11-12 19:57 Marek Polacek
2015-11-12 20:59 ` Joseph Myers
0 siblings, 1 reply; 2+ messages in thread
From: Marek Polacek @ 2015-11-12 19:57 UTC (permalink / raw)
To: GCC Patches, Joseph Myers
As explained in the PR, the issue here was that we were treating a TYPENAME
wrongly as an ID. That happened because we were using information from the
wrong scope when parsing a token after an else clause. I.e. in fn1 in the
attached testcase we need to examine the token after "if (1);" to see if it's
the "else" keyword, but when it's not, we use the scope of the for loop when
classifying the token, so we wrongly see "T" as a identifier of a variable.
Fixed by examining the token again and reclassifying it.
Moreover, we were ICEing in a similar scenario, treating ID as a TYPENAME, as
demonstrated in pr67784-2.c. The fix is analogical.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-11-12 Marek Polacek <polacek@redhat.com>
PR c/67784
* c-parser.c (c_parser_for_statement): Reclassify the token in
a correct scope.
* gcc.dg/pr67784-1.c: New test.
* gcc.dg/pr67784-2.c: New test.
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index 2484b92..8949825 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -5749,6 +5749,21 @@ c_parser_for_statement (c_parser *parser, bool ivdep)
c_finish_loop (loc, cond, incr, body, c_break_label, c_cont_label, true);
add_stmt (c_end_compound_stmt (loc, block, flag_isoc99 || c_dialect_objc ()));
+ /* We might need to reclassify any previously-lexed identifier, e.g.
+ when we've left a for loop with an if-statement without else in the
+ body - we might have used a wrong scope for the token. See PR67784. */
+ if (c_parser_next_token_is (parser, CPP_NAME))
+ {
+ c_token *token = c_parser_peek_token (parser);
+ tree decl = lookup_name (token->value);
+ if (decl == NULL_TREE)
+ ;
+ else if (TREE_CODE (decl) == TYPE_DECL)
+ token->id_kind = C_ID_TYPENAME;
+ else if (VAR_P (decl))
+ token->id_kind = C_ID_ID;
+ }
+
token_indent_info next_tinfo
= get_token_indent_info (c_parser_peek_token (parser));
warn_for_misleading_indentation (for_tinfo, body_tinfo, next_tinfo);
diff --git gcc/testsuite/gcc.dg/pr67784-1.c gcc/testsuite/gcc.dg/pr67784-1.c
index e69de29..d5e85fc 100644
--- gcc/testsuite/gcc.dg/pr67784-1.c
+++ gcc/testsuite/gcc.dg/pr67784-1.c
@@ -0,0 +1,54 @@
+/* PR c/67784 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+typedef int T;
+
+void
+fn1 (void)
+{
+ for (int T;;)
+ if (1)
+ ;
+ T *x;
+}
+
+void
+fn2 (void)
+{
+ for (int T;;)
+ if (1)
+ T = 1;
+ T *x;
+}
+
+void
+fn3 (void)
+{
+ for (int T;;)
+ if (1)
+ {
+ }
+ T *x;
+}
+
+void
+fn4 (void)
+{
+ for (int T;;)
+ if (1)
+L:
+ ;
+ T *x;
+}
+
+void
+fn5 (void)
+{
+ for (int T;;)
+ if (1)
+ ;
+ else
+ ;
+ T *x;
+}
diff --git gcc/testsuite/gcc.dg/pr67784-2.c gcc/testsuite/gcc.dg/pr67784-2.c
index e69de29..de3b1c8 100644
--- gcc/testsuite/gcc.dg/pr67784-2.c
+++ gcc/testsuite/gcc.dg/pr67784-2.c
@@ -0,0 +1,54 @@
+/* PR c/67784 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+int T;
+
+void
+fn1 (void)
+{
+ for (typedef int T;;) /* { dg-error "declaration of non-variable" } */
+ if (1)
+ ;
+ T *x; /* { dg-error "undeclared" } */
+}
+
+void
+fn2 (void)
+{
+ for (typedef int T;;) /* { dg-error "declaration of non-variable" } */
+ if (1)
+ T = 1; /* { dg-error "expected expression" } */
+ T *x; /* { dg-error "undeclared" } */
+}
+
+void
+fn3 (void)
+{
+ for (typedef int T;;) /* { dg-error "declaration of non-variable" } */
+ if (1)
+ {
+ }
+ T *x; /* { dg-error "undeclared" } */
+}
+
+void
+fn4 (void)
+{
+ for (typedef int T;;) /* { dg-error "declaration of non-variable" } */
+ if (1)
+L:
+ ;
+ T *x; /* { dg-error "undeclared" } */
+}
+
+void
+fn5 (void)
+{
+ for (typedef int T;;) /* { dg-error "declaration of non-variable" } */
+ if (1)
+ ;
+ else
+ ;
+ T *x; /* { dg-error "undeclared" } */
+}
Marek
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [C PATCH] Fix parsing when using declarations in for loops and typedefs (PR c/67784)
2015-11-12 19:57 [C PATCH] Fix parsing when using declarations in for loops and typedefs (PR c/67784) Marek Polacek
@ 2015-11-12 20:59 ` Joseph Myers
0 siblings, 0 replies; 2+ messages in thread
From: Joseph Myers @ 2015-11-12 20:59 UTC (permalink / raw)
To: Marek Polacek; +Cc: GCC Patches
On Thu, 12 Nov 2015, Marek Polacek wrote:
> As explained in the PR, the issue here was that we were treating a TYPENAME
> wrongly as an ID. That happened because we were using information from the
> wrong scope when parsing a token after an else clause. I.e. in fn1 in the
> attached testcase we need to examine the token after "if (1);" to see if it's
> the "else" keyword, but when it's not, we use the scope of the for loop when
> classifying the token, so we wrongly see "T" as a identifier of a variable.
> Fixed by examining the token again and reclassifying it.
>
> Moreover, we were ICEing in a similar scenario, treating ID as a TYPENAME, as
> demonstrated in pr67784-2.c. The fix is analogical.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-11-12 20:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-12 19:57 [C PATCH] Fix parsing when using declarations in for loops and typedefs (PR c/67784) Marek Polacek
2015-11-12 20:59 ` Joseph Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).