This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[C++] Fix parse.y warnings


Hi,

bison-1.34 introduced the following feature:

* A missing `;' ending a rule triggers a warning
  In accordance with POSIX, and in agreement with other
  Yacc implementations, Bison will mandate this semicolon in a near
  future.  This eases the implementation of a Bison parser of Bison
  grammars by making this grammar LALR(1) instead of LR(2).  To
  facilitate the transition, this release introduces a warning.

Indeed, during the build of the current head:

parse.y:597: warning: previous rule lacks an ending `;'
parse.y:646: warning: previous rule lacks an ending `;'
parse.y:1043: warning: previous rule lacks an ending `;'
parse.y:1050: warning: previous rule lacks an ending `;'
parse.y:1066: warning: previous rule lacks an ending `;'
parse.y:1081: warning: previous rule lacks an ending `;'
parse.y:1500: warning: previous rule lacks an ending `;'
parse.y:2189: warning: previous rule lacks an ending `;'
parse.y:2250: warning: previous rule lacks an ending `;'
parse.y:2683: warning: previous rule lacks an ending `;'

I have trivially fixed this by adding the missing ';' at the end of those rules.
Tested i686-pc-linux-gnu, c,c++.

Ok to commit the below? In case, what about a similar fix for 3_1?

Ciao,
Paolo.

/////////////

2002-03-21  Paolo Carlini  <pcarlini@unitus.it>

        * parse.y (namespace_qualifier, maybe_identifier,
        begin_explicit_instantiation, end_explicit_instantiation,
        apparent_template_type, .finish_template_type,
        do_id, maybe_init, defarg_again, component_decl_1):
        Add ending ';', in accordance with POSIX.

--- parse.y.orig Thu Mar 21 13:42:03 2002
+++ parse.y Thu Mar 21 13:46:45 2002
@@ -593,6 +593,7 @@
       $$ = lastiddecl;
     got_scope = $$;
   }
+        ;

 any_id:
    unqualified_id
@@ -642,6 +643,7 @@
     { $$ = $1; }
  | /* empty */
   { $$ = NULL_TREE; }
+        ;

 template_type_parm:
    aggr maybe_identifier
@@ -1039,9 +1041,11 @@

 begin_explicit_instantiation:
       { begin_explicit_instantiation(); }
+        ;

 end_explicit_instantiation:
       { end_explicit_instantiation(); }
+        ;

 /* The TYPENAME expansions are to deal with use of a template class name as
   a template within the class itself, where the template decl is hidden by
@@ -1062,6 +1066,7 @@
  | identifier '<' template_arg_list_opt '>'
      .finish_template_type
   { $$ = $5; }
+        ;

 self_template_type:
    SELFNAME  '<' template_arg_list_opt template_close_bracket
@@ -1077,6 +1082,7 @@
     $$ = finish_template_type ($<ttype>-3, $<ttype>-1,
           yychar == SCOPE);
   }
+        ;

 template_close_bracket:
    '>'
@@ -1496,6 +1502,7 @@
     else
       $$ = $<ttype>-1;
   }
+        ;

 template_id:
           PFUNCNAME '<' do_id template_arg_list_opt template_close_bracket
@@ -2182,6 +2189,7 @@
   { $$ = NULL_TREE; }
  | '=' init
   { $$ = $2; }
+        ;

 /* If we are processing a template, we don't want to expand this
    initializer yet.  */
@@ -2246,6 +2254,7 @@
   { replace_defarg ($1, $2); }
  | DEFARG_MARKER error END_OF_SAVED_INPUT
   { replace_defarg ($1, error_mark_node); }
+        ;

 pending_defargs:
    /* empty */ %prec EMPTY
@@ -2677,6 +2686,7 @@
   { $$ = grokfield ($$, NULL_TREE, $4, $2, $3); }
  | using_decl
   { $$ = do_class_using_decl ($1); }
+        ;

 /* The case of exactly one component is handled directly by component_decl.  */

 /* ??? Huh? ^^^ */



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]