This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[C++] Fix parse.y warnings
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: gcc-patches at gcc dot gnu dot org
- Cc: jason at redhat dot com
- Date: Thu, 21 Mar 2002 20:32:52 +0100
- Subject: [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? ^^^ */