]> git.saurik.com Git - bison.git/commitdiff
Merge branch 'maint'
authorAkim Demaille <akim@lrde.epita.fr>
Thu, 4 Oct 2012 15:16:00 +0000 (17:16 +0200)
committerAkim Demaille <akim@lrde.epita.fr>
Thu, 4 Oct 2012 15:16:00 +0000 (17:16 +0200)
* origin/maint:
  maint: word changes
  lalr1.cc: fix test suite portability
  maint: fix an erroneous include
  tests: check that headers are self contained
  doc: add missing documentation for --report

Conflicts:
NEWS
data/location.cc

1  2 
NEWS
README-hacking
THANKS
data/location.cc
doc/bison.texi
tests/headers.at

diff --combined NEWS
index a5c7a99dff06984aef67a8a624702428a6547729,c1ab7aa345348a3462e5c5d6b384ebfca33cc998..fd1cadd4c4dc7dcf16cedc28137e1b4748485af5
--- 1/NEWS
--- 2/NEWS
+++ b/NEWS
@@@ -2,242 -2,6 +2,242 @@@ GNU Bison NEW
  
  * Noteworthy changes in release ?.? (????-??-??) [?]
  
 +** Incompatible changes
 +
 +*** Obsolete features
 +
 +  Support for YYFAIL is removed (deprecated in Bison 2.4.2).
 +  Support for yystype and yyltype (instead of YYSTYPE and YYLTYPE)
 +  is removed (deprecated in Bison 1.875).
 +  Support for YYPARSE_PARAM is removed (deprecated in Bison 1.875).
 +
 +** Warnings
 +
 +*** Enhancements of the -Werror option
 +
 +  The -Werror=CATEGORY option is now recognized, and will treat specified
 +  warnings as errors. The warnings need not have been explictly activated
 +  using the -W option, this is similar to what gcc 4.7 does.
 +
 +  For example, given the following command line, Bison will treat both
 +  warnings related to POSIX Yacc incompatiblities and S/R conflicts as
 +  errors (and only those):
 +
 +    $ bison -Werror=yacc,error=conflicts-sr input.y
 +
 +  If no categories are specified, -Werror will make all active warnings into
 +  errors. For example, the following line does the same the previous example:
 +
 +    $ bison -Werror -Wnone -Wyacc -Wconflicts-sr input.y
 +
 +  (By default -Wconflicts-sr,conflicts-rr,deprecated,other is enabled.)
 +
 +  Note that the categories in this -Werror option may not be prefixed with
 +  "no-". However, -Wno-error[=CATEGORY] is valid.
 +
 +  Note that -y enables -Werror=yacc. Therefore it is now possible to require
 +  Yacc-like behavior (e.g., always generate y.tab.c), but to report
 +  incompatibilities as warnings: "-y -Wno-error=yacc".
 +
 +*** The display of warnings is now richer
 +
 +  The option that controls a given warning is now displayed:
 +
 +    foo.y:4.6: warning: type clash on default action: <foo> != <bar> [-Wother]
 +
 +  In the case of warnings treated as errors, the prefix is changed from
 +  "warning: " to "error: ", and the suffix is displayed, in a manner similar
 +  to gcc, as [-Werror=CATEGORY].
 +
 +  For instance, where the previous version of Bison would report (and exit
 +  with failure):
 +
 +    bison: warnings being treated as errors
 +    input.y:1.1: warning: stray ',' treated as white space
 +
 +  it now reports:
 +
 +    input.y:1.1: error: stray ',' treated as white space [-Werror=other]
 +
 +*** Deprecated constructs
 +
 +  The new 'deprecated' warning category flags obsolete constructs whose
 +  support will be discontinued.  It is enabled by default.  These warnings
 +  used to be reported as 'other' warnings.
 +
 +*** Useless semantic types
 +
 +  Bison now warns about useless (uninhabited) semantic types.  Since
 +  semantic types are not declared to Bison (they are defined in the opaque
 +  %union structure), it is %printer/%destructor directives about useless
 +  types that trigger the warning:
 +
 +    %token <type1> term
 +    %type  <type2> nterm
 +    %printer    {} <type1> <type3>
 +    %destructor {} <type2> <type4>
 +    %%
 +    nterm: term { $$ = $1; };
 +
 +    3.28-34: warning: type <type3> is used, but is not associated to any symbol
 +    4.28-34: warning: type <type4> is used, but is not associated to any symbol
 +
 +*** Undefined but unused symbols
 +
 +  Bison used to raise an error for undefined symbols that are not used in
 +  the grammar.  This is now only a warning.
 +
 +    %printer    {} symbol1
 +    %destructor {} symbol2
 +    %type <type>   symbol3
 +    %%
 +    exp: "a";
 +
 +*** Useless destructors or printers
 +
 +  Bison now warns about useless destructors or printers.  In the following
 +  example, the printer for <type1>, and the destructor for <type2> are
 +  useless: all symbols of <type1> (token1) already have a printer, and all
 +  symbols of type <type2> (token2) already have a destructor.
 +
 +    %token <type1> token1
 +           <type2> token2
 +           <type3> token3
 +           <type4> token4
 +    %printer    {} token1 <type1> <type3>
 +    %destructor {} token2 <type2> <type4>
 +
 +*** Conflicts
 +
 +  The warnings and error messages about shift/reduce and reduce/reduce
 +  conflicts have been normalized.  For instance on the following foo.y file:
 +
 +    %glr-parser
 +    %%
 +    exp: exp '+' exp | '0' | '0';
 +
 +  compare the previous version of bison:
 +
 +    $ bison foo.y
 +    foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
 +    $ bison -Werror foo.y
 +    bison: warnings being treated as errors
 +    foo.y: conflicts: 1 shift/reduce, 2 reduce/reduce
 +
 +  with the new behavior:
 +
 +    $ bison foo.y
 +    foo.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
 +    foo.y: warning: 2 reduce/reduce conflicts [-Wconflicts-rr]
 +    $ bison -Werror foo.y
 +    foo.y: error: 1 shift/reduce conflict [-Werror=conflicts-sr]
 +    foo.y: error: 2 reduce/reduce conflicts [-Werror=conflicts-rr]
 +
 +  When %expect or %expect-rr is used, such as with bar.y:
 +
 +    %expect 0
 +    %glr-parser
 +    %%
 +    exp: exp '+' exp | '0' | '0';
 +
 +  Former behavior:
 +
 +    $ bison bar.y
 +    bar.y: conflicts: 1 shift/reduce, 2 reduce/reduce
 +    bar.y: expected 0 shift/reduce conflicts
 +    bar.y: expected 0 reduce/reduce conflicts
 +
 +  New one:
 +
 +    $ bison bar.y
 +    bar.y: error: shift/reduce conflicts: 1 found, 0 expected
 +    bar.y: error: reduce/reduce conflicts: 2 found, 0 expected
 +
 +** Additional yylex/yyparse arguments
 +
 +  The new directive %param declares additional arguments to both yylex and
 +  yyparse.  The %lex-param, %parse-param, and %param directives support one
 +  or more arguments.  Instead of
 +
 +    %lex-param   {arg1_type *arg1}
 +    %lex-param   {arg2_type *arg2}
 +    %parse-param {arg1_type *arg1}
 +    %parse-param {arg2_type *arg2}
 +
 +  one may now declare
 +
 +    %param {arg1_type *arg1} {arg2_type *arg2}
 +
 +** Java skeleton improvements
 +
 +  The constants for token names were moved to the Lexer interface.  Also, it
 +  is possible to add code to the parser's constructors using "%code init"
 +  and "%define init_throws".
 +
 +** C++ skeletons improvements
 +
 +*** The parser header is no longer mandatory (lalr1.cc, glr.cc)
 +
 +  Using %defines is now optional.  Without it, the needed support classes
 +  are defined in the generated parser, instead of additional files (such as
 +  location.hh, position.hh and stack.hh).
 +
 +*** Locations are no longer mandatory (lalr1.cc, glr.cc)
 +
 +  Both lalr1.cc and glr.cc no longer require %location.
 +
 +*** syntax_error exception (lalr1.cc)
 +
 +  The C++ parser features a syntax_error exception, which can be
 +  thrown from the scanner or from user rules to raise syntax errors.
 +  This facilitates reporting errors caught in sub-functions (e.g.,
 +  rejecting too large integral literals from a conversion function
 +  used by the scanner, or rejecting invalid combinations from a
 +  factory invoked by the user actions).
 +
 +** Variable api.tokens.prefix
 +
 +  The variable api.tokens.prefix changes the way tokens are identified in
 +  the generated files.  This is especially useful to avoid collisions
 +  with identifiers in the target language.  For instance
 +
 +    %token FILE for ERROR
 +    %define api.tokens.prefix "TOK_"
 +    %%
 +    start: FILE for ERROR;
 +
 +  will generate the definition of the symbols TOK_FILE, TOK_for, and
 +  TOK_ERROR in the generated sources.  In particular, the scanner must
 +  use these prefixed token names, although the grammar itself still
 +  uses the short names (as in the sample rule given above).
 +
 +** Variable api.namespace
 +
 +  The 'namespace' variable is renamed 'api.namespace'.  Backward
 +  compatibility is ensured, but upgrading is recommended.
 +
 +** Variable parse.error
 +
 +  This variable controls the verbosity of error messages.  The use of the
 +  %error-verbose directive is deprecated in favor of "%define parse.error
 +  verbose".
 +
 +** Semantic predicates
 +
 +  The new, experimental, semantic-predicate feature allows actions of the
 +  form "%?{ BOOLEAN-EXPRESSION }", which cause syntax errors (as for
 +  YYERROR) if the expression evaluates to 0, and are evaluated immediately
 +  in GLR parsers, rather than being deferred.  The result is that they allow
 +  the programmer to prune possible parses based on the values of run-time
 +  expressions.
 +
 +** The directive %expect-rr is now an error in non GLR mode
 +
 +  It used to be an error only if used in non GLR mode, _and_ if there are
 +  reduce/reduce conflicts.
 +
 +* Noteworthy changes in release ?.? (????-??-??) [?]
 +
  ** Bug fixes
  
    Bugs in the test suite have been fixed.
    Incorrect definitions of YY_, issued by yacc.c when no parser header is
    generated, are removed.
  
+   All the generated headers are self-contained.
  ** Changes in the format of error messages
  
    This used to be the format of many error reports:
  
  * Noteworthy changes in release 2.6.1 (2012-07-30) [stable]
  
 -  Bison no longer executes user-specified M4 code when processing a grammar.
 + Bison no longer executes user-specified M4 code when processing a grammar.
  
  ** Future Changes
  
  
  * Noteworthy changes in release 2.6 (2012-07-19) [stable]
  
 -** Future Changes
 +** Future changes:
  
    The next major release of Bison will drop support for the following
    deprecated features.  Please report disagreements to bug-bison@gnu.org.
@@@ -2130,8 -1896,7 +2132,8 @@@ along with this program.  If not, see <
   LocalWords:  namespaces strerror const autoconfiguration Dconst Autoconf's FDL
   LocalWords:  Automake TMPDIR LESSEQ ylwrap endif yydebug YYTOKEN YYLSP ival hh
   LocalWords:  extern YYTOKENTYPE TOKENTYPE yytokentype tokentype STYPE lval pdf
 - LocalWords:  lang yyoutput dvi html ps POSIX lvalp llocp calc yyo fval
 + LocalWords:  lang yyoutput dvi html ps POSIX lvalp llocp Wother nterm arg init
-  LocalWords:  TOK
++ LocalWords:  TOK calc yyo fval
  
  Local Variables:
  mode: outline
diff --combined README-hacking
index 2b92edcf0c7c1ae97f4b3799a594da35a9c9bd9e,26391e98f7cd256b04ae950d4721c1f6c260fc19..988bd3044cb778ddf1e23f56b13eb984d2d07c53
@@@ -35,13 -35,6 +35,13 @@@ of the .output file etc.  This exclude
  (comparable to assert/abort), and all the --trace output which is
  meant for the maintainers only.
  
 +** Horizontal tabs
 +Do not add horizontal tab characters to any file in Bison's repository
 +except where required.  For example, do not use tabs to format C code.
 +However, make files, ChangeLog, and some regular expressions require
 +tabs.  Also, test cases might need to contain tabs to check that Bison
 +properly processes tabs in its input.
 +
  
  * Working from the repository
  
@@@ -175,6 -168,19 +175,19 @@@ decide whether to update
  ** make check
  Use liberally.
  
+ ** Typical errors
+ If the test suite shows failures such as the following one
+   .../bison/lib/getopt.h:196:8: error: redefinition of 'struct option'
+   /usr/include/getopt.h:54:8: error: previous definition of 'struct option'
+ it probably means that some file was compiled without
+ AT_DATA_SOURCE_PROLOGUE.  This error is due to the fact that our -I options
+ pick up gnulib's replacement headers, such as getopt.h, and this will go
+ wrong if config.h was not included first.
+ See tests/local.at for details.
  ** make maintainer-check-valgrind
  This target uses valgrind both to check bison, and the generated parsers.
  
@@@ -233,9 -239,6 +246,9 @@@ release
    that it does not make sense for glr.c, which should be ANSI, but
    currently is actually GNU C, nor for lalr1.cc.
  
 +- Test with a very recent version of GCC for both C and C++.  Testing
 +  with older versions that are still in use is nice too.
 +
  
  * Release Procedure
  This section needs to be updated to take into account features from
diff --combined THANKS
index 19ec28a9fb11828b8ad02368de1c746069cdee82,f742e8f850b494f4f2ff7b4a18f5eba70b8c6c96..b83ec0e5ee05409f15ca5d2f2106d26ff29a02cc
--- 1/THANKS
--- 2/THANKS
+++ b/THANKS
@@@ -5,7 -5,7 +5,7 @@@ Airy Andre                Airy.Andre@ed
  Akim Demaille             akim@freefriends.org
  Albert Chin-A-Young       china@thewrittenword.com
  Alexander Belopolsky      alexb@rentec.com
- Alexandre Duret-Lutz      adl@src.lip6.fr
+ Alexandre Duret-Lutz      adl@lrde.epita.fr
  Andreas Schwab            schwab@suse.de
  Andrew Suffield           asuffield@users.sourceforge.net
  Angelo Borsotti           angelo.borsotti@gmail.com
@@@ -71,7 -71,6 +71,7 @@@ Matt Kraai                kraai@alumni.
  Matt Rosing               rosing@peakfive.com
  Michael Hayes             m.hayes@elec.canterbury.ac.nz
  Michael Raskin            7c6f434c@mail.ru
 +Michiel De Wilde          mdewilde.agilent@gmail.com
  Mickael Labau             labau_m@epita.fr
  Mike Castle               dalgoda@ix.netcom.com
  Neil Booth                NeilB@earthling.net
@@@ -89,12 -88,12 +89,13 @@@ Per Allansson             per@appgate.c
  Peter Fales               psfales@lucent.com
  Peter Hamorsky            hamo@upjs.sk
  Piotr Gackiewicz          gacek@intertel.com.pl
 +Quentin Hocquet           hocquet@gostai.com
  Quoc Peyrot               chojin@lrde.epita.fr
  R Blake                   blakers@mac.com
  Raja R Harinath           harinath@cs.umn.edu
  Ralf Wildenhues           Ralf.Wildenhues@gmx.de
  Richard Stallman          rms@gnu.org
+ Rob Vermaas               rob.vermaas@gmail.com
  Robert Anisko             anisko_r@epita.fr
  Satya Kiran Popuri        satyakiran@gmail.com
  Sebastian Setzer          sebastian.setzer.ext@siemens.com
diff --combined data/location.cc
index 218910b133344b88a8759864f31b5b9e21359881,92b6d0967fad7dfbaa8e1ebb3630b6c28ca00526..14688ca4e32f57034507ae8a7fe82084b23c97a7
@@@ -1,6 -1,6 +1,6 @@@
  # C++ skeleton for Bison
  
 -# Copyright (C) 2002-2007, 2009-2012 Free Software Foundation, Inc.
 +# Copyright (C) 2002-2012 Free Software Foundation, Inc.
  
  # This program is free software: you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
  # You should have received a copy of the GNU General Public License
  # along with this program.  If not, see <http://www.gnu.org/licenses/>.
  
 -# We do want M4 expansion after # for CPP macros.
 -m4_changecom()
 -m4_divert_push(0)dnl
 -@output(b4_dir_prefix[]position.hh@)@
 -b4_copyright([Positions for Bison parsers in C++],
 -             [2002-2007, 2009-2012])[
 -
 -/**
 - ** \file ]b4_dir_prefix[position.hh
 - ** Define the ]b4_namespace_ref[::position class.
 - */
 -
 -]b4_cpp_guard_open([b4_dir_prefix[]position.hh])[
 -
 -# include <algorithm> // std::max
 -# include <iostream>
 -# include <string>
 -
 -]b4_null_define[
 +m4_pushdef([b4_copyright_years],
 +           [2002-2012])
  
 -]b4_namespace_open[
 -  /// Abstract a position.
 +# b4_position_define
 +# ------------------
 +# Define class position.
 +m4_define([b4_position_define],
 +[[  /// Abstract a position.
    class position
    {
    public:
        ostr << *pos.filename << ':';
      return ostr << pos.line << '.' << pos.column;
    }
 +]])
  
 -]b4_namespace_close[
 -]b4_cpp_guard_close([b4_dir_prefix[]position.hh])
 -@output(b4_dir_prefix[]location.hh@)@
 -b4_copyright([Locations for Bison parsers in C++],
 -             [2002-2007, 2009-2012])[
 -
 -/**
 - ** \file ]b4_dir_prefix[location.hh
 - ** Define the ]b4_namespace_ref[::location class.
 - */
 -
 -]b4_cpp_guard_open([b4_dir_prefix[]location.hh])[
 -
 -# include "position.hh"
 -
 -]b4_namespace_open[
  
 -  /// Abstract a location.
 +# b4_location_define
 +# ------------------
 +m4_define([b4_location_define],
 +[[  /// Abstract a location.
    class location
    {
    public:
      position last = loc.end - 1;
      ostr << loc.begin;
      if (last.filename
 -      && (!loc.begin.filename
 -          || *loc.begin.filename != *last.filename))
 +        && (!loc.begin.filename
 +            || *loc.begin.filename != *last.filename))
        ostr << '-' << last;
      else if (loc.begin.line != last.line)
        ostr << '-' << last.line  << '.' << last.column;
        ostr << '-' << last.column;
      return ostr;
    }
 +]])
 +
  
- # include <iosfwd>
 +# We do want M4 expansion after # for CPP macros.
 +m4_changecom()
 +b4_defines_if([
 +m4_divert_push(0)dnl
 +@output(b4_dir_prefix[]position.hh@)@
 +b4_copyright([Positions for Bison parsers in C++])[
 +
 +/**
 + ** \file ]b4_dir_prefix[position.hh
 + ** Define the ]b4_namespace_ref[::position class.
 + */
 +
 +]b4_cpp_guard_open([b4_dir_prefix[]position.hh])[
 +
 +# include <algorithm> // std::max
++# include <iostream>
 +# include <string>
 +
 +]b4_null_define[
 +
 +]b4_namespace_open[
 +]b4_position_define[
  ]b4_namespace_close[
 +]b4_cpp_guard_close([b4_dir_prefix[]position.hh])
 +@output(b4_dir_prefix[]location.hh@)@
 +b4_copyright([Locations for Bison parsers in C++])[
 +
 +/**
 + ** \file ]b4_dir_prefix[location.hh
 + ** Define the ]b4_namespace_ref[::location class.
 + */
 +
 +]b4_cpp_guard_open([b4_dir_prefix[]location.hh])[
  
- # include <iostream>
- # include <string>
 +# include "position.hh"
 +
 +]b4_namespace_open[
 +]b4_location_define[
 +]b4_namespace_close[
  ]b4_cpp_guard_close([b4_dir_prefix[]location.hh])
  m4_divert_pop(0)
 +])# b4_defines_if
 +m4_popdef([b4_copyright_years])dnl
  m4_changecom([#])
diff --combined doc/bison.texi
index 0e3a2500eb860a45b21c2eb0dcb8ef55723d34e3,ba18d9a9d32ff700b1d2e9c47ce757b8dd194531..4ab00c6545db048c0123401265463968881ca102
@@@ -135,8 -135,7 +135,8 @@@ Writing GLR Parser
  
  * Simple GLR Parsers::     Using GLR parsers on unambiguous grammars.
  * Merging GLR Parses::     Using GLR parsers to resolve ambiguities.
 -* GLR Semantic Actions::   Deferred semantic actions have special concerns.
 +* GLR Semantic Actions::   Considerations for semantic values and deferred actions.
 +* Semantic Predicates::    Controlling a parse with arbitrary computations.
  * Compiler Requirements::  GLR parsers require a modern C compiler.
  
  Examples
@@@ -163,9 -162,9 +163,9 @@@ Reverse Polish Notation Calculato
  
  Grammar Rules for @code{rpcalc}
  
 -* Rpcalc Input::
 -* Rpcalc Line::
 -* Rpcalc Expr::
 +* Rpcalc Input::            Explanation of the @code{input} nonterminal
 +* Rpcalc Line::             Explanation of the @code{line} nonterminal
 +* Rpcalc Expr::             Explanation of the @code{expr} nonterminal
  
  Location Tracking Calculator: @code{ltcalc}
  
@@@ -178,8 -177,6 +178,8 @@@ Multi-Function Calculator: @code{mfcalc
  * Mfcalc Declarations::    Bison declarations for multi-function calculator.
  * Mfcalc Rules::           Grammar rules for the calculator.
  * Mfcalc Symbol Table::    Symbol table management subroutines.
 +* Mfcalc Lexer::           The lexical analyzer.
 +* Mfcalc Main::            The controlling function.
  
  Bison Grammar Files
  
@@@ -276,8 -273,7 +276,8 @@@ The Bison Parser Algorith
  Operator Precedence
  
  * Why Precedence::    An example showing why precedence is needed.
 -* Using Precedence::  How to specify precedence in Bison grammars.
 +* Using Precedence::  How to specify precedence and associativity.
 +* Precedence Only::   How to specify precedence only.
  * Precedence Examples::  How these features are used in the previous example.
  * How Precedence::    How they work.
  
@@@ -773,8 -769,7 +773,8 @@@ merged result
  @menu
  * Simple GLR Parsers::     Using GLR parsers on unambiguous grammars.
  * Merging GLR Parses::     Using GLR parsers to resolve ambiguities.
 -* GLR Semantic Actions::   Deferred semantic actions have special concerns.
 +* GLR Semantic Actions::   Considerations for semantic values and deferred actions.
 +* Semantic Predicates::    Controlling a parse with arbitrary computations.
  * Compiler Requirements::  GLR parsers require a modern C compiler.
  @end menu
  
@@@ -1142,10 -1137,6 +1142,10 @@@ the offending merge
  @node GLR Semantic Actions
  @subsection GLR Semantic Actions
  
 +The nature of GLR parsing and the structure of the generated
 +parsers give rise to certain restrictions on semantic values and actions.
 +
 +@subsubsection Deferred semantic actions
  @cindex deferred semantic actions
  By definition, a deferred semantic action is not performed at the same time as
  the associated reduction.
@@@ -1179,7 -1170,6 +1179,7 @@@ For example, if a semantic action migh
  to invoke @code{yyclearin} (@pxref{Action Features}) or to attempt to free
  memory referenced by @code{yylval}.
  
 +@subsubsection YYERROR
  @findex YYERROR
  @cindex GLR parsers and @code{YYERROR}
  Another Bison feature requiring special consideration is @code{YYERROR}
  initiate error recovery.
  During deterministic GLR operation, the effect of @code{YYERROR} is
  the same as its effect in a deterministic parser.
 -In a deferred semantic action, its effect is undefined.
 -@c The effect is probably a syntax error at the split point.
 +The effect in a deferred action is similar, but the precise point of the
 +error is undefined;  instead, the parser reverts to deterministic operation,
 +selecting an unspecified stack on which to continue with a syntax error.
 +In a semantic predicate (see @ref{Semantic Predicates}) during nondeterministic
 +parsing, @code{YYERROR} silently prunes
 +the parse that invoked the test.
 +
 +@subsubsection Restrictions on semantic values and locations
 +GLR parsers require that you use POD (Plain Old Data) types for
 +semantic values and location types when using the generated parsers as
 +C++ code.
 +
 +@node Semantic Predicates
 +@subsection Controlling a Parse with Arbitrary Predicates
 +@findex %?
 +@cindex Semantic predicates in GLR parsers
 +
 +In addition to the @code{%dprec} and @code{%merge} directives,
 +GLR parsers
 +allow you to reject parses on the basis of arbitrary computations executed
 +in user code, without having Bison treat this rejection as an error
 +if there are alternative parses. (This feature is experimental and may
 +evolve.  We welcome user feedback.)  For example,
 +
 +@example
 +widget:
 +  %?@{  new_syntax @} "widget" id new_args  @{ $$ = f($3, $4); @}
 +| %?@{ !new_syntax @} "widget" id old_args  @{ $$ = f($3, $4); @}
 +;
 +@end example
 +
 +@noindent
 +is one way to allow the same parser to handle two different syntaxes for
 +widgets.  The clause preceded by @code{%?} is treated like an ordinary
 +action, except that its text is treated as an expression and is always
 +evaluated immediately (even when in nondeterministic mode).  If the
 +expression yields 0 (false), the clause is treated as a syntax error,
 +which, in a nondeterministic parser, causes the stack in which it is reduced
 +to die.  In a deterministic parser, it acts like YYERROR.
 +
 +As the example shows, predicates otherwise look like semantic actions, and
 +therefore you must be take them into account when determining the numbers
 +to use for denoting the semantic values of right-hand side symbols.
 +Predicate actions, however, have no defined value, and may not be given
 +labels.
  
 -Also, see @ref{Location Default Action, ,Default Action for Locations}, which
 -describes a special usage of @code{YYLLOC_DEFAULT} in GLR parsers.
 +There is a subtle difference between semantic predicates and ordinary
 +actions in nondeterministic mode, since the latter are deferred.
 +For example, we could try to rewrite the previous example as
 +
 +@example
 +widget:
 +  @{ if (!new_syntax) YYERROR; @}
 +    "widget" id new_args  @{ $$ = f($3, $4); @}
 +|  @{ if (new_syntax) YYERROR; @}
 +    "widget" id old_args   @{ $$ = f($3, $4); @}
 +;
 +@end example
 +
 +@noindent
 +(reversing the sense of the predicate tests to cause an error when they are
 +false).  However, this
 +does @emph{not} have the same effect if @code{new_args} and @code{old_args}
 +have overlapping syntax.
 +Since the mid-rule actions testing @code{new_syntax} are deferred,
 +a GLR parser first encounters the unresolved ambiguous reduction
 +for cases where @code{new_args} and @code{old_args} recognize the same string
 +@emph{before} performing the tests of @code{new_syntax}.  It therefore
 +reports an error.
 +
 +Finally, be careful in writing predicates: deferred actions have not been
 +evaluated, so that using them in a predicate will have undefined effects.
  
  @node Compiler Requirements
  @subsection Considerations when Compiling GLR Parsers
@@@ -1527,13 -1450,11 +1527,13 @@@ The source code for this calculator is 
  Here are the C and Bison declarations for the reverse polish notation
  calculator.  As in C, comments are placed between @samp{/*@dots{}*/}.
  
 +@comment file: rpcalc.y
  @example
  /* Reverse polish notation calculator.  */
  
  %@{
    #define YYSTYPE double
 +  #include <stdio.h>
    #include <math.h>
    int yylex (void);
    void yyerror (char const *);
@@@ -1578,7 -1499,6 +1578,7 @@@ type for numeric constants
  
  Here are the grammar rules for the reverse polish notation calculator.
  
 +@comment file: rpcalc.y
  @example
  @group
  input:
@@@ -1627,9 -1547,9 +1627,9 @@@ main job of most actions.  The semanti
  rule are referred to as @code{$1}, @code{$2}, and so on.
  
  @menu
 -* Rpcalc Input::
 -* Rpcalc Line::
 -* Rpcalc Expr::
 +* Rpcalc Input::            Explanation of the @code{input} nonterminal
 +* Rpcalc Line::             Explanation of the @code{line} nonterminal
 +* Rpcalc Expr::             Explanation of the @code{expr} nonterminal
  @end menu
  
  @node Rpcalc Input
@@@ -1793,7 -1713,6 +1793,7 @@@ A token type code of zero is returned i
  
  Here is the code for the lexical analyzer:
  
 +@comment file: rpcalc.y
  @example
  @group
  /* The lexical analyzer returns a double floating point
@@@ -1842,7 -1761,6 +1842,7 @@@ In keeping with the spirit of this exam
  kept to the bare minimum.  The only requirement is that it call
  @code{yyparse} to start the process of parsing.
  
 +@comment file: rpcalc.y
  @example
  @group
  int
@@@ -1863,7 -1781,6 +1863,7 @@@ always @code{"syntax error"}).  It is u
  @code{yyerror} (@pxref{Interface, ,Parser C-Language Interface}), so
  here is the definition we will use:
  
 +@comment file: rpcalc.y
  @example
  @group
  #include <stdio.h>
@@@ -1948,15 -1865,15 +1948,15 @@@ example session using @code{rpcalc}
  @example
  $ @kbd{rpcalc}
  @kbd{4 9 +}
 -13
 +@result{} 13
  @kbd{3 7 + 3 4 5 *+-}
 --13
 +@result{} -13
  @kbd{3 7 + 3 4 5 * + - n}              @r{Note the unary minus, @samp{n}}
 -13
 +@result{} 13
  @kbd{5 6 / 4 n +}
 --3.166666667
 +@result{} -3.166666667
  @kbd{3 4 ^}                            @r{Exponentiation}
 -81
 +@result{} 81
  @kbd{^D}                               @r{End-of-file indicator}
  $
  @end example
@@@ -1990,8 -1907,8 +1990,8 @@@ parentheses nested to arbitrary depth
  %token NUM
  %left '-' '+'
  %left '*' '/'
 -%left NEG     /* negation--unary minus */
 -%right '^'    /* exponentiation */
 +%precedence NEG   /* negation--unary minus */
 +%right '^'        /* exponentiation */
  @end group
  
  %% /* The grammar follows.  */
@@@ -2034,16 -1951,15 +2034,16 @@@ In the second section (Bison declaratio
  types and says they are left-associative operators.  The declarations
  @code{%left} and @code{%right} (right associativity) take the place of
  @code{%token} which is used to declare a token type name without
 -associativity.  (These tokens are single-character literals, which
 +associativity/precedence.  (These tokens are single-character literals, which
  ordinarily don't need to be declared.  We declare them here to specify
 -the associativity.)
 +the associativity/precedence.)
  
  Operator precedence is determined by the line ordering of the
  declarations; the higher the line number of the declaration (lower on
  the page or screen), the higher the precedence.  Hence, exponentiation
  has the highest precedence, unary minus (@code{NEG}) is next, followed
 -by @samp{*} and @samp{/}, and so on.  @xref{Precedence, ,Operator
 +by @samp{*} and @samp{/}, and so on.  Unary minus is not associative,
 +only precedence matters (@code{%precedence}. @xref{Precedence, ,Operator
  Precedence}.
  
  The other important new feature is the @code{%prec} in the grammar
@@@ -2147,7 -2063,7 +2147,7 @@@ the same as the declarations for the in
  
  %left '-' '+'
  %left '*' '/'
 -%left NEG
 +%precedence NEG
  %right '^'
  
  %% /* The grammar follows.  */
@@@ -2348,23 -2264,19 +2348,23 @@@ to create named variables, store value
  Here is a sample session with the multi-function calculator:
  
  @example
 +@group
  $ @kbd{mfcalc}
  @kbd{pi = 3.141592653589}
 -3.1415926536
 +@result{} 3.1415926536
 +@end group
 +@group
  @kbd{sin(pi)}
 -0.0000000000
 +@result{} 0.0000000000
 +@end group
  @kbd{alpha = beta1 = 2.3}
 -2.3000000000
 +@result{} 2.3000000000
  @kbd{alpha}
 -2.3000000000
 +@result{} 2.3000000000
  @kbd{ln(alpha)}
 -0.8329091229
 +@result{} 0.8329091229
  @kbd{exp(ln(beta1))}
 -2.3000000000
 +@result{} 2.3000000000
  $
  @end example
  
@@@ -2374,8 -2286,6 +2374,8 @@@ Note that multiple assignment and neste
  * Mfcalc Declarations::    Bison declarations for multi-function calculator.
  * Mfcalc Rules::           Grammar rules for the calculator.
  * Mfcalc Symbol Table::    Symbol table management subroutines.
 +* Mfcalc Lexer::           The lexical analyzer.
 +* Mfcalc Main::            The controlling function.
  @end menu
  
  @node Mfcalc Declarations
@@@ -2387,9 -2297,8 +2387,9 @@@ Here are the C and Bison declarations f
  @example
  @group
  %@{
 -  #include <math.h>  /* For math functions, cos(), sin(), etc.  */
 -  #include "calc.h"  /* Contains definition of `symrec'.  */
 +  #include <stdio.h>  /* For printf, etc. */
 +  #include <math.h>   /* For pow, used in the grammar.  */
 +  #include "calc.h"   /* Contains definition of `symrec'.  */
    int yylex (void);
    void yyerror (char const *);
  %@}
  %right '='
  %left '-' '+'
  %left '*' '/'
 -%left NEG     /* negation--unary minus */
 -%right '^'    /* exponentiation */
 +%precedence NEG /* negation--unary minus */
 +%right '^'      /* exponentiation */
  @end group
  @end example
  
@@@ -2526,11 -2435,23 +2526,11 @@@ symrec *getsym (char const *)
  @end group
  @end example
  
 -The new version of @code{main} includes a call to @code{init_table}, a
 -function that initializes the symbol table.  Here it is, and
 -@code{init_table} as well:
 +The new version of @code{main} will call @code{init_table} to initialize
 +the symbol table:
  
  @comment file: mfcalc.y: 3
  @example
 -#include <stdio.h>
 -
 -@group
 -/* Called by yyparse on error.  */
 -void
 -yyerror (char const *s)
 -@{
 -  printf ("%s\n", s);
 -@}
 -@end group
 -
  @group
  struct init
  @{
  @group
  struct init const arith_fncts[] =
  @{
 -  "sin",  sin,
 -  "cos",  cos,
 -  "atan", atan,
 -  "ln",   log,
 -  "exp",  exp,
 -  "sqrt", sqrt,
 -  0, 0
 +  @{ "atan", atan @},
 +  @{ "cos",  cos  @},
 +  @{ "exp",  exp  @},
 +  @{ "ln",   log  @},
 +  @{ "sin",  sin  @},
 +  @{ "sqrt", sqrt @},
 +  @{ 0, 0 @},
  @};
  @end group
  
@@@ -2559,7 -2480,6 +2559,7 @@@ symrec *sym_table
  
  @group
  /* Put arithmetic functions in table.  */
 +static
  void
  init_table (void)
  @{
      @}
  @}
  @end group
 -
 -@group
 -int
 -main (void)
 -@{
 -  init_table ();
 -  return yyparse ();
 -@}
 -@end group
  @end example
  
  By simply editing the initialization list and adding the necessary include
@@@ -2610,16 -2539,13 +2610,16 @@@ getsym (char const *sym_name
    symrec *ptr;
    for (ptr = sym_table; ptr != (symrec *) 0;
         ptr = (symrec *)ptr->next)
 -    if (strcmp (ptr->name,sym_name) == 0)
 +    if (strcmp (ptr->name, sym_name) == 0)
        return ptr;
    return 0;
  @}
  @end group
  @end example
  
 +@node Mfcalc Lexer
 +@subsection The @code{mfcalc} Lexer
 +
  The function @code{yylex} must now recognize variables, numeric values, and
  the single-character arithmetic operators.  Strings of alphanumeric
  characters with a leading letter are recognized as either variables or
@@@ -2676,6 -2602,7 +2676,6 @@@ yylex (void
        symrec *s;
        int i;
  @end group
 -
        if (!symbuf)
          symbuf = (char *) malloc (length + 1);
  
  @end group
  @end example
  
 +@node Mfcalc Main
 +@subsection The @code{mfcalc} Main
 +
  The error reporting function is unchanged, and the new version of
  @code{main} includes a call to @code{init_table} and sets the @code{yydebug}
  on user demand (@xref{Tracing, , Tracing Your Parser}, for details):
@@@ -4376,8 -4300,7 +4376,8 @@@ Bison will convert this into a @code{#d
  the parser, so that the function @code{yylex} (if it is in this file)
  can use the name @var{name} to stand for this token type's code.
  
 -Alternatively, you can use @code{%left}, @code{%right}, or
 +Alternatively, you can use @code{%left}, @code{%right},
 +@code{%precedence}, or
  @code{%nonassoc} instead of @code{%token}, if you wish to specify
  associativity and precedence.  @xref{Precedence Decl, ,Operator
  Precedence}.
@@@ -4453,8 -4376,7 +4453,8 @@@ of ``$end''
  @cindex declaring operator precedence
  @cindex operator precedence, declaring
  
 -Use the @code{%left}, @code{%right} or @code{%nonassoc} declaration to
 +Use the @code{%left}, @code{%right}, @code{%nonassoc}, or
 +@code{%precedence} declaration to
  declare a token and specify its precedence and associativity, all at
  once.  These are called @dfn{precedence declarations}.
  @xref{Precedence, ,Operator Precedence}, for general information on
@@@ -4490,10 -4412,6 +4490,10 @@@ left-associativity (grouping @var{x} wi
  means that @samp{@var{x} @var{op} @var{y} @var{op} @var{z}} is
  considered a syntax error.
  
 +@code{%precedence} gives only precedence to the @var{symbols}, and
 +defines no associativity at all.  Use this to define precedence only,
 +and leave any potential conflict due to associativity enabled.
 +
  @item
  The precedence of an operator determines how it nests with other operators.
  All the tokens declared in a single precedence declaration have equal
@@@ -4955,7 -4873,7 +4955,7 @@@ statically allocated variables for comm
  including @code{yylval} and @code{yylloc}.)
  
  Alternatively, you can generate a pure, reentrant parser.  The Bison
 -declaration @code{%define api.pure} says that you want the parser to be
 +declaration @samp{%define api.pure} says that you want the parser to be
  reentrant.  It looks like this:
  
  @example
@@@ -5059,14 -4977,14 +5059,14 @@@ for use by the next invocation of the @
  
  Bison also supports both the push parser interface along with the pull parser
  interface in the same generated parser.  In order to get this functionality,
 -you should replace the @code{%define api.push-pull push} declaration with the
 -@code{%define api.push-pull both} declaration.  Doing this will create all of
 +you should replace the @samp{%define api.push-pull push} declaration with the
 +@samp{%define api.push-pull both} declaration.  Doing this will create all of
  the symbols mentioned earlier along with the two extra symbols, @code{yyparse}
  and @code{yypull_parse}.  @code{yyparse} can be used exactly as it normally
  would be used.  However, the user should note that it is implemented in the
  generated parser by calling @code{yypull_parse}.
  This makes the @code{yyparse} function that is generated with the
 -@code{%define api.push-pull both} declaration slower than the normal
 +@samp{%define api.push-pull both} declaration slower than the normal
  @code{yyparse} function.  If the user
  calls the @code{yypull_parse} function it will parse the rest of the input
  stream.  It is possible to @code{yypush_parse} tokens to select a subgrammar
@@@ -5082,9 -5000,9 +5082,9 @@@ yypull_parse (ps); /* Will call the lex
  yypstate_delete (ps);
  @end example
  
 -Adding the @code{%define api.pure} declaration does exactly the same thing to
 -the generated parser with @code{%define api.push-pull both} as it did for
 -@code{%define api.push-pull push}.
 +Adding the @samp{%define api.pure} declaration does exactly the same thing to
 +the generated parser with @samp{%define api.push-pull both} as it did for
 +@samp{%define api.push-pull push}.
  
  @node Decl Summary
  @subsection Bison Declaration Summary
@@@ -5157,8 -5075,10 +5157,8 @@@ default location or at the location spe
  @end deffn
  
  @deffn {Directive} %debug
 -In the parser implementation file, define the macro @code{YYDEBUG} (or
 -@code{@var{prefix}DEBUG} with @samp{%define api.prefix @var{prefix}}, see
 -@ref{Multiple Parsers, ,Multiple Parsers in the Same Program}) to 1 if it is
 -not already defined, so that the debugging facilities are compiled.
 +Instrument the parser for traces.  Obsoleted by @samp{%define
 +parse.trace}.
  @xref{Tracing, ,Tracing Your Parser}.
  @end deffn
  
@@@ -5254,22 -5174,6 +5254,22 @@@ grammar does not use it, using @samp{%l
  accurate syntax error messages.
  @end deffn
  
 +@deffn {Directive} %name-prefix "@var{prefix}"
 +Rename the external symbols used in the parser so that they start with
 +@var{prefix} instead of @samp{yy}.  The precise list of symbols renamed
 +in C parsers
 +is @code{yyparse}, @code{yylex}, @code{yyerror}, @code{yynerrs},
 +@code{yylval}, @code{yychar}, @code{yydebug}, and
 +(if locations are used) @code{yylloc}.  If you use a push parser,
 +@code{yypush_parse}, @code{yypull_parse}, @code{yypstate},
 +@code{yypstate_new} and @code{yypstate_delete} will
 +also be renamed.  For example, if you use @samp{%name-prefix "c_"}, the
 +names become @code{c_parse}, @code{c_lex}, and so on.
 +For C++ parsers, see the @samp{%define api.namespace} documentation in this
 +section.
 +@xref{Multiple Parsers, ,Multiple Parsers in the Same Program}.
 +@end deffn
 +
  @ifset defaultprec
  @deffn {Directive} %no-default-prec
  Do not assign a precedence to rules lacking an explicit @code{%prec}
@@@ -5293,7 -5197,7 +5293,7 @@@ Specify @var{file} for the parser imple
  @end deffn
  
  @deffn {Directive} %pure-parser
 -Deprecated version of @code{%define api.pure} (@pxref{%define
 +Deprecated version of @samp{%define api.pure} (@pxref{%define
  Summary,,api.pure}), for which Bison is more careful to warn about
  unreasonable usage.
  @end deffn
@@@ -5416,62 -5320,9 +5416,62 @@@ Summary,,%skeleton})
  Unaccepted @var{variable}s produce an error.
  Some of the accepted @var{variable}s are:
  
 -@itemize @bullet
 +@table @code
 +@c ================================================== api.namespace
 +@item api.namespace
 +@findex %define api.namespace
 +@itemize
 +@item Languages(s): C++
 +
 +@item Purpose: Specify the namespace for the parser class.
 +For example, if you specify:
 +
 +@example
 +%define api.namespace "foo::bar"
 +@end example
 +
 +Bison uses @code{foo::bar} verbatim in references such as:
 +
 +@example
 +foo::bar::parser::semantic_type
 +@end example
 +
 +However, to open a namespace, Bison removes any leading @code{::} and then
 +splits on any remaining occurrences:
 +
 +@example
 +namespace foo @{ namespace bar @{
 +  class position;
 +  class location;
 +@} @}
 +@end example
 +
 +@item Accepted Values:
 +Any absolute or relative C++ namespace reference without a trailing
 +@code{"::"}.  For example, @code{"foo"} or @code{"::foo::bar"}.
 +
 +@item Default Value:
 +The value specified by @code{%name-prefix}, which defaults to @code{yy}.
 +This usage of @code{%name-prefix} is for backward compatibility and can
 +be confusing since @code{%name-prefix} also specifies the textual prefix
 +for the lexical analyzer function.  Thus, if you specify
 +@code{%name-prefix}, it is best to also specify @samp{%define
 +api.namespace} so that @code{%name-prefix} @emph{only} affects the
 +lexical analyzer function.  For example, if you specify:
 +
 +@example
 +%define api.namespace "foo"
 +%name-prefix "bar::"
 +@end example
 +
 +The parser namespace is @code{foo} and @code{yylex} is referenced as
 +@code{bar::lex}.
 +@end itemize
 +@c namespace
 +
 +
  @c ================================================== api.prefix
 -@item @code{api.prefix}
 +@item api.prefix
  @findex %define api.prefix
  
  @itemize @bullet
  @end itemize
  
  @c ================================================== api.pure
 -@item @code{api.pure}
 +@item api.pure
  @findex %define api.pure
  
  @itemize @bullet
  
  @item Default Value: @code{false}
  @end itemize
 +@c api.pure
 +
  
 -@c ================================================== api.push-pull
  
 -@item @code{api.push-pull}
 +@c ================================================== api.push-pull
 +@item api.push-pull
  @findex %define api.push-pull
  
  @itemize @bullet
@@@ -5521,73 -5370,10 +5521,73 @@@ More user feedback will help to stabili
  
  @item Default Value: @code{pull}
  @end itemize
 +@c api.push-pull
 +
 +
 +
 +@c ================================================== api.tokens.prefix
 +@item api.tokens.prefix
 +@findex %define api.tokens.prefix
 +
 +@itemize
 +@item Languages(s): all
 +
 +@item Purpose:
 +Add a prefix to the token names when generating their definition in the
 +target language.  For instance
 +
 +@example
 +%token FILE for ERROR
 +%define api.tokens.prefix "TOK_"
 +%%
 +start: FILE for ERROR;
 +@end example
 +
 +@noindent
 +generates the definition of the symbols @code{TOK_FILE}, @code{TOK_for},
 +and @code{TOK_ERROR} in the generated source files.  In particular, the
 +scanner must use these prefixed token names, while the grammar itself
 +may still use the short names (as in the sample rule given above).  The
 +generated informational files (@file{*.output}, @file{*.xml},
 +@file{*.dot}) are not modified by this prefix.  See @ref{Calc++ Parser}
 +and @ref{Calc++ Scanner}, for a complete example.
 +
 +@item Accepted Values:
 +Any string.  Should be a valid identifier prefix in the target language,
 +in other words, it should typically be an identifier itself (sequence of
 +letters, underscores, and ---not at the beginning--- digits).
 +
 +@item Default Value:
 +empty
 +@end itemize
 +@c api.tokens.prefix
 +
 +
 +@c ================================================== lex_symbol
 +@item lex_symbol
 +@findex %define lex_symbol
 +
 +@itemize @bullet
 +@item Language(s):
 +C++
 +
 +@item Purpose:
 +When variant-based semantic values are enabled (@pxref{C++ Variants}),
 +request that symbols be handled as a whole (type, value, and possibly
 +location) in the scanner.  @xref{Complete Symbols}, for details.
 +
 +@item Accepted Values:
 +Boolean.
 +
 +@item Default Value:
 +@code{false}
 +@end itemize
 +@c lex_symbol
 +
  
  @c ================================================== lr.default-reductions
  
 -@item @code{lr.default-reductions}
 +@item lr.default-reductions
  @findex %define lr.default-reductions
  
  @itemize @bullet
@@@ -5608,7 -5394,7 +5608,7 @@@ feedback will help to stabilize it.
  
  @c ============================================ lr.keep-unreachable-states
  
 -@item @code{lr.keep-unreachable-states}
 +@item lr.keep-unreachable-states
  @findex %define lr.keep-unreachable-states
  
  @itemize @bullet
@@@ -5618,11 -5404,10 +5618,11 @@@ remain in the parser tables.  @xref{Unr
  @item Accepted Values: Boolean
  @item Default Value: @code{false}
  @end itemize
 +@c lr.keep-unreachable-states
  
  @c ================================================== lr.type
  
 -@item @code{lr.type}
 +@item lr.type
  @findex %define lr.type
  
  @itemize @bullet
@@@ -5637,62 -5422,62 +5637,62 @@@ More user feedback will help to stabili
  @item Default Value: @code{lalr}
  @end itemize
  
 -@c ================================================== namespace
  
 -@item @code{namespace}
 +@c ================================================== namespace
 +@item namespace
  @findex %define namespace
 +Obsoleted by @code{api.namespace}
 +@c namespace
  
 -@itemize
 -@item Languages(s): C++
  
 -@item Purpose: Specify the namespace for the parser class.
 -For example, if you specify:
 +@c ================================================== parse.assert
 +@item parse.assert
 +@findex %define parse.assert
  
 -@smallexample
 -%define namespace "foo::bar"
 -@end smallexample
 +@itemize
 +@item Languages(s): C++
  
 -Bison uses @code{foo::bar} verbatim in references such as:
 +@item Purpose: Issue runtime assertions to catch invalid uses.
 +In C++, when variants are used (@pxref{C++ Variants}), symbols must be
 +constructed and
 +destroyed properly.  This option checks these constraints.
  
 -@smallexample
 -foo::bar::parser::semantic_type
 -@end smallexample
 +@item Accepted Values: Boolean
  
 -However, to open a namespace, Bison removes any leading @code{::} and then
 -splits on any remaining occurrences:
 +@item Default Value: @code{false}
 +@end itemize
 +@c parse.assert
  
 -@smallexample
 -namespace foo @{ namespace bar @{
 -  class position;
 -  class location;
 -@} @}
 -@end smallexample
 -
 -@item Accepted Values: Any absolute or relative C++ namespace reference without
 -a trailing @code{"::"}.
 -For example, @code{"foo"} or @code{"::foo::bar"}.
 -
 -@item Default Value: The value specified by @code{%name-prefix}, which defaults
 -to @code{yy}.
 -This usage of @code{%name-prefix} is for backward compatibility and can be
 -confusing since @code{%name-prefix} also specifies the textual prefix for the
 -lexical analyzer function.
 -Thus, if you specify @code{%name-prefix}, it is best to also specify
 -@code{%define namespace} so that @code{%name-prefix} @emph{only} affects the
 -lexical analyzer function.
 -For example, if you specify:
  
 -@smallexample
 -%define namespace "foo"
 -%name-prefix "bar::"
 -@end smallexample
 +@c ================================================== parse.error
 +@item parse.error
 +@findex %define parse.error
 +@itemize
 +@item Languages(s):
 +all
 +@item Purpose:
 +Control the kind of error messages passed to the error reporting
 +function.  @xref{Error Reporting, ,The Error Reporting Function
 +@code{yyerror}}.
 +@item Accepted Values:
 +@itemize
 +@item @code{simple}
 +Error messages passed to @code{yyerror} are simply @w{@code{"syntax
 +error"}}.
 +@item @code{verbose}
 +Error messages report the unexpected token, and possibly the expected ones.
 +However, this report can often be incorrect when LAC is not enabled
 +(@pxref{LAC}).
 +@end itemize
  
 -The parser namespace is @code{foo} and @code{yylex} is referenced as
 -@code{bar::lex}.
 +@item Default Value:
 +@code{simple}
  @end itemize
 +@c parse.error
 +
  
  @c ================================================== parse.lac
 -@item @code{parse.lac}
 +@item parse.lac
  @findex %define parse.lac
  
  @itemize
@@@ -5703,50 -5488,7 +5703,50 @@@ syntax error handling.  @xref{LAC}
  @item Accepted Values: @code{none}, @code{full}
  @item Default Value: @code{none}
  @end itemize
 +@c parse.lac
 +
 +@c ================================================== parse.trace
 +@item parse.trace
 +@findex %define parse.trace
 +
 +@itemize
 +@item Languages(s): C, C++, Java
 +
 +@item Purpose: Require parser instrumentation for tracing.
 +@xref{Tracing, ,Tracing Your Parser}.
 +
 +In C/C++, define the macro @code{YYDEBUG} (or @code{@var{prefix}DEBUG} with
 +@samp{%define api.prefix @var{prefix}}), see @ref{Multiple Parsers,
 +,Multiple Parsers in the Same Program}) to 1 in the parser implementation
 +file if it is not already defined, so that the debugging facilities are
 +compiled.
 +
 +@item Accepted Values: Boolean
 +
 +@item Default Value: @code{false}
  @end itemize
 +@c parse.trace
 +
 +@c ================================================== variant
 +@item variant
 +@findex %define variant
 +
 +@itemize @bullet
 +@item Language(s):
 +C++
 +
 +@item Purpose:
 +Request variant-based semantic values.
 +@xref{C++ Variants}.
 +
 +@item Accepted Values:
 +Boolean.
 +
 +@item Default Value:
 +@code{false}
 +@end itemize
 +@c variant
 +@end table
  
  
  @node %code Summary
@@@ -5792,7 -5534,7 +5792,7 @@@ file
  Not all qualifiers are accepted for all target languages.  Unaccepted
  qualifiers produce an error.  Some of the accepted qualifiers are:
  
 -@itemize @bullet
 +@table @code
  @item requires
  @findex %code requires
  
@@@ -5856,7 -5598,7 +5856,7 @@@ parser implementation file.  For exampl
  @item Location(s): The parser Java file after any Java package directive and
  before any class definitions.
  @end itemize
 -@end itemize
 +@end table
  
  Though we say the insertion locations are language-dependent, they are
  technically skeleton-dependent.  Writers of non-standard skeletons
@@@ -6018,10 -5760,10 +6018,10 @@@ If you use a reentrant parser, you can 
  parameter information to it in a reentrant way.  To do so, use the
  declaration @code{%parse-param}:
  
 -@deffn {Directive} %parse-param @{@var{argument-declaration}@}
 +@deffn {Directive} %parse-param @{@var{argument-declaration}@} @dots{}
  @findex %parse-param
 -Declare that an argument declared by the braced-code
 -@var{argument-declaration} is an additional @code{yyparse} argument.
 +Declare that one or more
 +@var{argument-declaration} are additional @code{yyparse} arguments.
  The @var{argument-declaration} is used when declaring
  functions or prototypes.  The last identifier in
  @var{argument-declaration} must be the argument name.
  Here's an example.  Write this in the parser:
  
  @example
 -%parse-param @{int *nastiness@}
 -%parse-param @{int *randomness@}
 +%parse-param @{int *nastiness@} @{int *randomness@}
  @end example
  
  @noindent
@@@ -6060,8 -5803,8 +6060,8 @@@ exp: @dots{}    @{ @dots{}; *randomnes
  More user feedback will help to stabilize it.)
  
  You call the function @code{yypush_parse} to parse a single token.  This
 -function is available if either the @code{%define api.push-pull push} or
 -@code{%define api.push-pull both} declaration is used.
 +function is available if either the @samp{%define api.push-pull push} or
 +@samp{%define api.push-pull both} declaration is used.
  @xref{Push Decl, ,A Push Parser}.
  
  @deftypefun int yypush_parse (yypstate *yyps)
@@@ -6078,7 -5821,7 +6078,7 @@@ required to finish parsing the grammar
  More user feedback will help to stabilize it.)
  
  You call the function @code{yypull_parse} to parse the rest of the input
 -stream.  This function is available if the @code{%define api.push-pull both}
 +stream.  This function is available if the @samp{%define api.push-pull both}
  declaration is used.
  @xref{Push Decl, ,A Push Parser}.
  
@@@ -6094,8 -5837,8 +6094,8 @@@ The value returned by @code{yypull_pars
  More user feedback will help to stabilize it.)
  
  You call the function @code{yypstate_new} to create a new parser instance.
 -This function is available if either the @code{%define api.push-pull push} or
 -@code{%define api.push-pull both} declaration is used.
 +This function is available if either the @samp{%define api.push-pull push} or
 +@samp{%define api.push-pull both} declaration is used.
  @xref{Push Decl, ,A Push Parser}.
  
  @deftypefun {yypstate*} yypstate_new (void)
@@@ -6113,8 -5856,8 +6113,8 @@@ allocated
  More user feedback will help to stabilize it.)
  
  You call the function @code{yypstate_delete} to delete a parser instance.
 -function is available if either the @code{%define api.push-pull push} or
 -@code{%define api.push-pull both} declaration is used.
 +function is available if either the @samp{%define api.push-pull push} or
 +@samp{%define api.push-pull both} declaration is used.
  @xref{Push Decl, ,A Push Parser}.
  
  @deftypefun void yypstate_delete (yypstate *yyps)
@@@ -6303,7 -6046,7 +6303,7 @@@ The data type of @code{yylloc} has the 
  @node Pure Calling
  @subsection Calling Conventions for Pure Parsers
  
 -When you use the Bison declaration @code{%define api.pure} to request a
 +When you use the Bison declaration @samp{%define api.pure} to request a
  pure, reentrant parser, the global communication variables @code{yylval}
  and @code{yylloc} cannot be used.  (@xref{Pure Decl, ,A Pure (Reentrant)
  Parser}.)  In such parsers the two global variables are replaced by
@@@ -6327,57 -6070,46 +6327,57 @@@ textual locations, then the type @code{
  this case, omit the second argument; @code{yylex} will be called with
  only one argument.
  
 -
 -If you wish to pass the additional parameter data to @code{yylex}, use
 +If you wish to pass additional arguments to @code{yylex}, use
  @code{%lex-param} just like @code{%parse-param} (@pxref{Parser
 -Function}).
 +Function}).  To pass additional arguments to both @code{yylex} and
 +@code{yyparse}, use @code{%param}.
  
 -@deffn {Directive} lex-param @{@var{argument-declaration}@}
 +@deffn {Directive} %lex-param @{@var{argument-declaration}@} @dots{}
  @findex %lex-param
 -Declare that the braced-code @var{argument-declaration} is an
 -additional @code{yylex} argument declaration.
 +Specify that @var{argument-declaration} are additional @code{yylex} argument
 +declarations.  You may pass one or more such declarations, which is
 +equivalent to repeating @code{%lex-param}.
 +@end deffn
 +
 +@deffn {Directive} %param @{@var{argument-declaration}@} @dots{}
 +@findex %param
 +Specify that @var{argument-declaration} are additional
 +@code{yylex}/@code{yyparse} argument declaration.  This is equivalent to
 +@samp{%lex-param @{@var{argument-declaration}@} @dots{} %parse-param
 +@{@var{argument-declaration}@} @dots{}}.  You may pass one or more
 +declarations, which is equivalent to repeating @code{%param}.
  @end deffn
  
  For instance:
  
  @example
 -%parse-param @{int *nastiness@}
 -%lex-param   @{int *nastiness@}
 -%parse-param @{int *randomness@}
 +%lex-param   @{scanner_mode *mode@}
 +%parse-param @{parser_mode *mode@}
 +%param       @{environment_type *env@}
  @end example
  
  @noindent
  results in the following signatures:
  
  @example
 -int yylex   (int *nastiness);
 -int yyparse (int *nastiness, int *randomness);
 +int yylex   (scanner_mode *mode, environment_type *env);
 +int yyparse (parser_mode *mode, environment_type *env);
  @end example
  
 -If @code{%define api.pure} is added:
 +If @samp{%define api.pure} is added:
  
  @example
 -int yylex   (YYSTYPE *lvalp, int *nastiness);
 -int yyparse (int *nastiness, int *randomness);
 +int yylex   (YYSTYPE *lvalp, scanner_mode *mode, environment_type *env);
 +int yyparse (parser_mode *mode, environment_type *env);
  @end example
  
  @noindent
 -and finally, if both @code{%define api.pure} and @code{%locations} are used:
 +and finally, if both @samp{%define api.pure} and @code{%locations} are used:
  
  @example
 -int yylex   (YYSTYPE *lvalp, YYLTYPE *llocp, int *nastiness);
 -int yyparse (int *nastiness, int *randomness);
 +int yylex   (YYSTYPE *lvalp, YYLTYPE *llocp,
 +             scanner_mode *mode, environment_type *env);
 +int yyparse (parser_mode *mode, environment_type *env);
  @end example
  
  @node Error Reporting
  @cindex parse error
  @cindex syntax error
  
 -The Bison parser detects a @dfn{syntax error} or @dfn{parse error}
 +The Bison parser detects a @dfn{syntax error} (or @dfn{parse error})
  whenever it reads a token which cannot satisfy any syntax rule.  An
  action in the grammar can also explicitly proclaim an error, using the
  macro @code{YYERROR} (@pxref{Action Features, ,Special Features for Use
@@@ -6399,8 -6131,8 +6399,8 @@@ called by @code{yyparse} whenever a syn
  receives one argument.  For a syntax error, the string is normally
  @w{@code{"syntax error"}}.
  
 -@findex %error-verbose
 -If you invoke the directive @code{%error-verbose} in the Bison declarations
 +@findex %define parse.error
 +If you invoke @samp{%define parse.error verbose} in the Bison declarations
  section (@pxref{Bison Declarations, ,The Bison Declarations Section}), then
  Bison provides a more verbose and specific error message string instead of
  just plain @w{@code{"syntax error"}}.  However, that message sometimes
@@@ -6458,7 -6190,7 +6458,7 @@@ void yyerror (int *nastiness, char cons
  Finally, GLR and Yacc parsers share the same @code{yyerror} calling
  convention for absolutely pure parsers, i.e., when the calling
  convention of @code{yylex} @emph{and} the calling convention of
 -@code{%define api.pure} are pure.
 +@samp{%define api.pure} are pure.
  I.e.:
  
  @example
@@@ -6980,8 -6712,7 +6980,8 @@@ shift and when to reduce
  
  @menu
  * Why Precedence::    An example showing why precedence is needed.
 -* Using Precedence::  How to specify precedence in Bison grammars.
 +* Using Precedence::  How to specify precedence and associativity.
 +* Precedence Only::   How to specify precedence only.
  * Precedence Examples::  How these features are used in the previous example.
  * How Precedence::    How they work.
  @end menu
@@@ -7037,9 -6768,8 +7037,9 @@@ makes right-associativity
  @node Using Precedence
  @subsection Specifying Operator Precedence
  @findex %left
 -@findex %right
  @findex %nonassoc
 +@findex %precedence
 +@findex %right
  
  Bison allows you to specify these choices with the operator precedence
  declarations @code{%left} and @code{%right}.  Each such declaration
@@@ -7049,63 -6779,13 +7049,63 @@@ those operators left-associative and th
  them right-associative.  A third alternative is @code{%nonassoc}, which
  declares that it is a syntax error to find the same operator twice ``in a
  row''.
 +The last alternative, @code{%precedence}, allows to define only
 +precedence and no associativity at all.  As a result, any
 +associativity-related conflict that remains will be reported as an
 +compile-time error.  The directive @code{%nonassoc} creates run-time
 +error: using the operator in a associative way is a syntax error.  The
 +directive @code{%precedence} creates compile-time errors: an operator
 +@emph{can} be involved in an associativity-related conflict, contrary to
 +what expected the grammar author.
  
  The relative precedence of different operators is controlled by the
 -order in which they are declared.  The first @code{%left} or
 -@code{%right} declaration in the file declares the operators whose
 +order in which they are declared.  The first precedence/associativity
 +declaration in the file declares the operators whose
  precedence is lowest, the next such declaration declares the operators
  whose precedence is a little higher, and so on.
  
 +@node Precedence Only
 +@subsection Specifying Precedence Only
 +@findex %precedence
 +
 +Since POSIX Yacc defines only @code{%left}, @code{%right}, and
 +@code{%nonassoc}, which all defines precedence and associativity, little
 +attention is paid to the fact that precedence cannot be defined without
 +defining associativity.  Yet, sometimes, when trying to solve a
 +conflict, precedence suffices.  In such a case, using @code{%left},
 +@code{%right}, or @code{%nonassoc} might hide future (associativity
 +related) conflicts that would remain hidden.
 +
 +The dangling @code{else} ambiguity (@pxref{Shift/Reduce, , Shift/Reduce
 +Conflicts}) can be solved explicitly.  This shift/reduce conflicts occurs
 +in the following situation, where the period denotes the current parsing
 +state:
 +
 +@example
 +if @var{e1} then if  @var{e2} then @var{s1} . else @var{s2}
 +@end example
 +
 +The conflict involves the reduction of the rule @samp{IF expr THEN
 +stmt}, which precedence is by default that of its last token
 +(@code{THEN}), and the shifting of the token @code{ELSE}.  The usual
 +disambiguation (attach the @code{else} to the closest @code{if}),
 +shifting must be preferred, i.e., the precedence of @code{ELSE} must be
 +higher than that of @code{THEN}.  But neither is expected to be involved
 +in an associativity related conflict, which can be specified as follows.
 +
 +@example
 +%precedence THEN
 +%precedence ELSE
 +@end example
 +
 +The unary-minus is another typical example where associativity is
 +usually over-specified, see @ref{Infix Calc, , Infix Notation
 +Calculator: @code{calc}}.  The @code{%left} directive is traditionally
 +used to declare the precedence of @code{NEG}, which is more than needed
 +since it also defines its associativity.  While this is harmless in the
 +traditional example, who knows how @code{NEG} might be used in future
 +evolutions of the grammar@dots{}
 +
  @node Precedence Examples
  @subsection Precedence Examples
  
@@@ -7167,8 -6847,8 +7167,8 @@@ outlandish at first, but it is really v
  sign typically has a very high precedence as a unary operator, and a
  somewhat lower precedence (lower than multiplication) as a binary operator.
  
 -The Bison precedence declarations, @code{%left}, @code{%right} and
 -@code{%nonassoc}, can only be used once for a given token; so a token has
 +The Bison precedence declarations
 +can only be used once for a given token; so a token has
  only one precedence declared in this way.  For context-dependent
  precedence, you need to use an additional mechanism: the @code{%prec}
  modifier for rules.
@@@ -7513,9 -7193,9 +7513,9 @@@ The default behavior of Bison's LR-base
  historical reasons, but that behavior is often not robust.  For example, in
  the previous section, we discussed the mysterious conflicts that can be
  produced by LALR(1), Bison's default parser table construction algorithm.
 -Another example is Bison's @code{%error-verbose} directive, which instructs
 -the generated parser to produce verbose syntax error messages, which can
 -sometimes contain incorrect information.
 +Another example is Bison's @code{%define parse.error verbose} directive,
 +which instructs the generated parser to produce verbose syntax error
 +messages, which can sometimes contain incorrect information.
  
  In this section, we explore several modern features of Bison that allow you
  to tune fundamental aspects of the generated LR-based parsers.  Some of
@@@ -8039,14 -7719,12 +8039,14 @@@ that allows variable-length arrays.  Th
  
  Do not allow @code{YYINITDEPTH} to be greater than @code{YYMAXDEPTH}.
  
 -@c FIXME: C++ output.
 -Because of semantic differences between C and C++, the deterministic
 -parsers in C produced by Bison cannot grow when compiled
 -by C++ compilers.  In this precise case (compiling a C parser as C++) you are
 -suggested to grow @code{YYINITDEPTH}.  The Bison maintainers hope to fix
 -this deficiency in a future release.
 +You can generate a deterministic parser containing C++ user code from
 +the default (C) skeleton, as well as from the C++ skeleton
 +(@pxref{C++ Parsers}).  However, if you do use the default skeleton
 +and want to allow the parsing stack to grow,
 +be careful not to use semantic types or location types that require
 +non-trivial copy constructors.
 +The C skeleton bypasses these constructors when copying data to
 +new, larger stacks.
  
  @node Error Recovery
  @chapter Error Recovery
@@@ -8853,19 -8531,12 +8853,19 @@@ otherwise it defines @code{YYDEBUG} to 
  @item the directive @samp{%debug}
  @findex %debug
  Add the @code{%debug} directive (@pxref{Decl Summary, ,Bison Declaration
 -Summary}).  This is a Bison extension, especially useful for languages that
 -don't use a preprocessor.  Unless POSIX and Yacc portability matter to you,
 -this is the preferred solution.
 +Summary}).  This Bison extension is maintained for backward
 +compatibility with previous versions of Bison.
 +
 +@item the variable @samp{parse.trace}
 +@findex %define parse.trace
 +Add the @samp{%define parse.trace} directive (@pxref{%define
 +Summary,,parse.trace}), or pass the @option{-Dparse.trace} option
 +(@pxref{Bison Options}).  This is a Bison extension, which is especially
 +useful for languages that don't use a preprocessor.  Unless POSIX and Yacc
 +portability matter to you, this is the preferred solution.
  @end table
  
 -We suggest that you always enable the debug option so that debugging is
 +We suggest that you always enable the trace option so that debugging is
  always possible.
  
  @findex YYFPRINTF
@@@ -9264,10 -8935,6 +9264,10 @@@ unexpected number of conflicts is an er
  conflicts is not reported, so @option{-W} and @option{--warning} then have
  no effect on the conflict report.
  
 +@item deprecated
 +Deprecated constructs whose support will be removed in future versions of
 +Bison.
 +
  @item other
  All warnings not categorized above.  These warnings are enabled by default.
  
@@@ -9280,33 -8947,12 +9280,33 @@@ All the warnings
  @item none
  Turn off all the warnings.
  @item error
 -Treat warnings as errors.
 +See @option{-Werror}, below.
  @end table
  
  A category can be turned off by prefixing its name with @samp{no-}.  For
  instance, @option{-Wno-yacc} will hide the warnings about
  POSIX Yacc incompatibilities.
 +
 +@item -Werror[=@var{category}]
 +@itemx -Wno-error[=@var{category}]
 +Enable warnings falling in @var{category}, and treat them as errors.  If no
 +@var{category} is given, it defaults to making all enabled warnings into errors.
 +
 +@var{category} is the same as for @option{--warnings}, with the exception that
 +it may not be prefixed with @samp{no-} (see above).
 +
 +Prefixed with @samp{no}, it deactivates the error treatment for this
 +@var{category}. However, the warning itself won't be disabled, or enabled, by
 +this option.
 +
 +Note that the precedence of the @samp{=} and @samp{,} operators is such that
 +the following commands are @emph{not} equivalent, as the first will not treat
 +S/R conflicts as errors.
 +
 +@example
 +$ bison -Werror=yacc,conflicts-sr input.y
 +$ bison -Werror=yacc,error=conflicts-sr input.y
 +@end example
  @end table
  
  @noindent
@@@ -9426,13 -9072,23 +9426,23 @@@ separated list of @var{things} among
  Description of the grammar, conflicts (resolved and unresolved), and
  parser's automaton.
  
+ @item itemset
+ Implies @code{state} and augments the description of the automaton with
+ the full set of items for each state, instead of its core only.
  @item lookahead
  Implies @code{state} and augments the description of the automaton with
  each rule's lookahead set.
  
- @item itemset
- Implies @code{state} and augments the description of the automaton with
- the full set of items for each state, instead of its core only.
+ @item solved
+ Implies @code{state}.  Explain how conflicts were solved thanks to
+ precedence and associativity directives.
+ @item all
+ Enable all the items.
+ @item none
+ Do not generate the report.
  @end table
  
  @item --report-file=@var{file}
@@@ -9542,16 -9198,16 +9552,16 @@@ The C++ deterministic parser is selecte
  
  When run, @command{bison} will create several entities in the @samp{yy}
  namespace.
 -@findex %define namespace
 -Use the @samp{%define namespace} directive to change the namespace
 -name, see @ref{%define Summary,,namespace}.  The various classes are
 -generated in the following files:
 +@findex %define api.namespace
 +Use the @samp{%define api.namespace} directive to change the namespace name,
 +see @ref{%define Summary,,api.namespace}.  The various classes are generated
 +in the following files:
  
  @table @file
  @item position.hh
  @itemx location.hh
  The definition of the classes @code{position} and @code{location},
 -used for location tracking.  @xref{C++ Location Values}.
 +used for location tracking when enabled.  @xref{C++ Location Values}.
  
  @item stack.hh
  An auxiliary class @code{stack} used by the parser.
@@@ -9577,22 -9233,11 +9587,22 @@@ for a complete and accurate documentati
  @c - YYSTYPE
  @c - Printer and destructor
  
 +Bison supports two different means to handle semantic values in C++.  One is
 +alike the C interface, and relies on unions (@pxref{C++ Unions}).  As C++
 +practitioners know, unions are inconvenient in C++, therefore another
 +approach is provided, based on variants (@pxref{C++ Variants}).
 +
 +@menu
 +* C++ Unions::             Semantic values cannot be objects
 +* C++ Variants::           Using objects as semantic values
 +@end menu
 +
 +@node C++ Unions
 +@subsubsection C++ Unions
 +
  The @code{%union} directive works as for C, see @ref{Union Decl, ,The
  Collection of Value Types}.  In particular it produces a genuine
 -@code{union}@footnote{In the future techniques to allow complex types
 -within pseudo-unions (similar to Boost variants) might be implemented to
 -alleviate these issues.}, which have a few specific features in C++.
 +@code{union}, which have a few specific features in C++.
  @itemize @minus
  @item
  The type @code{YYSTYPE} is defined but its use is discouraged: rather
@@@ -9609,98 -9254,6 +9619,98 @@@ reclaimed automatically: using the @cod
  only means to avoid leaks.  @xref{Destructor Decl, , Freeing Discarded
  Symbols}.
  
 +@node C++ Variants
 +@subsubsection C++ Variants
 +
 +Starting with version 2.6, Bison provides a @emph{variant} based
 +implementation of semantic values for C++.  This alleviates all the
 +limitations reported in the previous section, and in particular, object
 +types can be used without pointers.
 +
 +To enable variant-based semantic values, set @code{%define} variable
 +@code{variant} (@pxref{%define Summary,, variant}).  Once this defined,
 +@code{%union} is ignored, and instead of using the name of the fields of the
 +@code{%union} to ``type'' the symbols, use genuine types.
 +
 +For instance, instead of
 +
 +@example
 +%union
 +@{
 +  int ival;
 +  std::string* sval;
 +@}
 +%token <ival> NUMBER;
 +%token <sval> STRING;
 +@end example
 +
 +@noindent
 +write
 +
 +@example
 +%token <int> NUMBER;
 +%token <std::string> STRING;
 +@end example
 +
 +@code{STRING} is no longer a pointer, which should fairly simplify the user
 +actions in the grammar and in the scanner (in particular the memory
 +management).
 +
 +Since C++ features destructors, and since it is customary to specialize
 +@code{operator<<} to support uniform printing of values, variants also
 +typically simplify Bison printers and destructors.
 +
 +Variants are stricter than unions.  When based on unions, you may play any
 +dirty game with @code{yylval}, say storing an @code{int}, reading a
 +@code{char*}, and then storing a @code{double} in it.  This is no longer
 +possible with variants: they must be initialized, then assigned to, and
 +eventually, destroyed.
 +
 +@deftypemethod {semantic_type} {T&} build<T> ()
 +Initialize, but leave empty.  Returns the address where the actual value may
 +be stored.  Requires that the variant was not initialized yet.
 +@end deftypemethod
 +
 +@deftypemethod {semantic_type} {T&} build<T> (const T& @var{t})
 +Initialize, and copy-construct from @var{t}.
 +@end deftypemethod
 +
 +
 +@strong{Warning}: We do not use Boost.Variant, for two reasons.  First, it
 +appeared unacceptable to require Boost on the user's machine (i.e., the
 +machine on which the generated parser will be compiled, not the machine on
 +which @command{bison} was run).  Second, for each possible semantic value,
 +Boost.Variant not only stores the value, but also a tag specifying its
 +type.  But the parser already ``knows'' the type of the semantic value, so
 +that would be duplicating the information.
 +
 +Therefore we developed light-weight variants whose type tag is external (so
 +they are really like @code{unions} for C++ actually).  But our code is much
 +less mature that Boost.Variant.  So there is a number of limitations in
 +(the current implementation of) variants:
 +@itemize
 +@item
 +Alignment must be enforced: values should be aligned in memory according to
 +the most demanding type.  Computing the smallest alignment possible requires
 +meta-programming techniques that are not currently implemented in Bison, and
 +therefore, since, as far as we know, @code{double} is the most demanding
 +type on all platforms, alignments are enforced for @code{double} whatever
 +types are actually used.  This may waste space in some cases.
 +
 +@item
 +Our implementation is not conforming with strict aliasing rules.  Alias
 +analysis is a technique used in optimizing compilers to detect when two
 +pointers are disjoint (they cannot ``meet'').  Our implementation breaks
 +some of the rules that G++ 4.4 uses in its alias analysis, so @emph{strict
 +alias analysis must be disabled}.  Use the option
 +@option{-fno-strict-aliasing} to compile the generated parser.
 +
 +@item
 +There might be portability issues we are not aware of.
 +@end itemize
 +
 +As far as we know, these limitations @emph{can} be alleviated.  All it takes
 +is some time and/or some talented C++ hacker willing to contribute to Bison.
  
  @node C++ Location Values
  @subsection C++ Location Values
@@@ -9844,7 -9397,7 +9854,7 @@@ additional argument for its constructor
  
  @defcv {Type} {parser} {semantic_type}
  @defcvx {Type} {parser} {location_type}
 -The types for semantics value and locations.
 +The types for semantic values and locations (if enabled).
  @end defcv
  
  @defcv {Type} {parser} {token}
@@@ -9855,27 -9408,11 +9865,27 @@@ use @code{yy::parser::token::FOO}.  Th
  (@pxref{Calc++ Scanner}).
  @end defcv
  
 +@defcv {Type} {parser} {syntax_error}
 +This class derives from @code{std::runtime_error}.  Throw instances of it
 +from the scanner or from the user actions to raise parse errors.  This is
 +equivalent with first
 +invoking @code{error} to report the location and message of the syntax
 +error, and then to invoke @code{YYERROR} to enter the error-recovery mode.
 +But contrary to @code{YYERROR} which can only be invoked from user actions
 +(i.e., written in the action itself), the exception can be thrown from
 +function invoked from the user action.
 +@end defcv
 +
  @deftypemethod {parser} {} parser (@var{type1} @var{arg1}, ...)
  Build a new parser object.  There are no arguments by default, unless
  @samp{%parse-param @{@var{type1} @var{arg1}@}} was used.
  @end deftypemethod
  
 +@deftypemethod {syntax_error} {} syntax_error (const location_type& @var{l}, const std::string& @var{m})
 +@deftypemethodx {syntax_error} {} syntax_error (const std::string& @var{m})
 +Instantiate a syntax-error exception.
 +@end deftypemethod
 +
  @deftypemethod {parser} {int} parse ()
  Run the syntactic analysis, and return 0 on success, 1 otherwise.
  @end deftypemethod
@@@ -9893,11 -9430,9 +9903,11 @@@ or nonzero, full tracing
  @end deftypemethod
  
  @deftypemethod {parser} {void} error (const location_type& @var{l}, const std::string& @var{m})
 +@deftypemethodx {parser} {void} error (const std::string& @var{m})
  The definition for this member function must be supplied by the user:
  the parser uses it to report a parser error occurring at @var{l},
 -described by @var{m}.
 +described by @var{m}.  If location tracking is not enabled, the second
 +signature is used.
  @end deftypemethod
  
  
  
  The parser invokes the scanner by calling @code{yylex}.  Contrary to C
  parsers, C++ parsers are always pure: there is no point in using the
 -@code{%define api.pure} directive.  Therefore the interface is as follows.
 +@samp{%define api.pure} directive.  The actual interface with @code{yylex}
 +depends whether you use unions, or variants.
 +
 +@menu
 +* Split Symbols::         Passing symbols as two/three components
 +* Complete Symbols::      Making symbols a whole
 +@end menu
 +
 +@node Split Symbols
 +@subsubsection Split Symbols
 +
 +Therefore the interface is as follows.
  
  @deftypemethod {parser} {int} yylex (semantic_type* @var{yylval}, location_type* @var{yylloc}, @var{type1} @var{arg1}, ...)
 -Return the next token.  Its type is the return value, its semantic
 -value and location being @var{yylval} and @var{yylloc}.  Invocations of
 +@deftypemethodx {parser} {int} yylex (semantic_type* @var{yylval}, @var{type1} @var{arg1}, ...)
 +Return the next token.  Its type is the return value, its semantic value and
 +location (if enabled) being @var{yylval} and @var{yylloc}.  Invocations of
  @samp{%lex-param @{@var{type1} @var{arg1}@}} yield additional arguments.
  @end deftypemethod
  
 +Note that when using variants, the interface for @code{yylex} is the same,
 +but @code{yylval} is handled differently.
 +
 +Regular union-based code in Lex scanner typically look like:
 +
 +@example
 +[0-9]+   @{
 +           yylval.ival = text_to_int (yytext);
 +           return yy::parser::INTEGER;
 +         @}
 +[a-z]+   @{
 +           yylval.sval = new std::string (yytext);
 +           return yy::parser::IDENTIFIER;
 +         @}
 +@end example
 +
 +Using variants, @code{yylval} is already constructed, but it is not
 +initialized.  So the code would look like:
 +
 +@example
 +[0-9]+   @{
 +           yylval.build<int>() = text_to_int (yytext);
 +           return yy::parser::INTEGER;
 +         @}
 +[a-z]+   @{
 +           yylval.build<std::string> = yytext;
 +           return yy::parser::IDENTIFIER;
 +         @}
 +@end example
 +
 +@noindent
 +or
 +
 +@example
 +[0-9]+   @{
 +           yylval.build(text_to_int (yytext));
 +           return yy::parser::INTEGER;
 +         @}
 +[a-z]+   @{
 +           yylval.build(yytext);
 +           return yy::parser::IDENTIFIER;
 +         @}
 +@end example
 +
 +
 +@node Complete Symbols
 +@subsubsection Complete Symbols
 +
 +If you specified both @code{%define variant} and @code{%define lex_symbol},
 +the @code{parser} class also defines the class @code{parser::symbol_type}
 +which defines a @emph{complete} symbol, aggregating its type (i.e., the
 +traditional value returned by @code{yylex}), its semantic value (i.e., the
 +value passed in @code{yylval}, and possibly its location (@code{yylloc}).
 +
 +@deftypemethod {symbol_type} {} symbol_type (token_type @var{type},  const semantic_type& @var{value}, const location_type& @var{location})
 +Build a complete terminal symbol which token type is @var{type}, and which
 +semantic value is @var{value}.  If location tracking is enabled, also pass
 +the @var{location}.
 +@end deftypemethod
 +
 +This interface is low-level and should not be used for two reasons.  First,
 +it is inconvenient, as you still have to build the semantic value, which is
 +a variant, and second, because consistency is not enforced: as with unions,
 +it is still possible to give an integer as semantic value for a string.
 +
 +So for each token type, Bison generates named constructors as follows.
 +
 +@deftypemethod {symbol_type} {} make_@var{token} (const @var{value_type}& @var{value}, const location_type& @var{location})
 +@deftypemethodx {symbol_type} {} make_@var{token} (const location_type& @var{location})
 +Build a complete terminal symbol for the token type @var{token} (not
 +including the @code{api.tokens.prefix}) whose possible semantic value is
 +@var{value} of adequate @var{value_type}.  If location tracking is enabled,
 +also pass the @var{location}.
 +@end deftypemethod
 +
 +For instance, given the following declarations:
 +
 +@example
 +%define api.tokens.prefix "TOK_"
 +%token <std::string> IDENTIFIER;
 +%token <int> INTEGER;
 +%token COLON;
 +@end example
 +
 +@noindent
 +Bison generates the following functions:
 +
 +@example
 +symbol_type make_IDENTIFIER(const std::string& v,
 +                            const location_type& l);
 +symbol_type make_INTEGER(const int& v,
 +                         const location_type& loc);
 +symbol_type make_COLON(const location_type& loc);
 +@end example
 +
 +@noindent
 +which should be used in a Lex-scanner as follows.
 +
 +@example
 +[0-9]+   return yy::parser::make_INTEGER(text_to_int (yytext), loc);
 +[a-z]+   return yy::parser::make_IDENTIFIER(yytext, loc);
 +":"      return yy::parser::make_COLON(loc);
 +@end example
 +
 +Tokens that do not have an identifier are not accessible: you cannot simply
 +use characters such as @code{':'}, they must be declared with @code{%token}.
  
  @node A Complete C++ Example
  @subsection A Complete C++ Example
  
  This section demonstrates the use of a C++ parser with a simple but
  complete example.  This example should be available on your system,
 -ready to compile, in the directory @dfn{../bison/examples/calc++}.  It
 +ready to compile, in the directory @dfn{.../bison/examples/calc++}.  It
  focuses on the use of Bison, therefore the design of the various C++
  classes is very naive: no accessors, no encapsulation of members etc.
  We will use a Lex scanner, and more precisely, a Flex scanner, to
 -demonstrate the various interaction.  A hand written scanner is
 +demonstrate the various interactions.  A hand-written scanner is
  actually easier to interface with.
  
  @menu
@@@ -10109,8 -9526,11 +10119,8 @@@ factor both as follows
  @comment file: calc++-driver.hh
  @example
  // Tell Flex the lexer's prototype ...
 -# define YY_DECL                                        \
 -  yy::calcxx_parser::token_type                         \
 -  yylex (yy::calcxx_parser::semantic_type* yylval,      \
 -         yy::calcxx_parser::location_type* yylloc,      \
 -         calcxx_driver& driver)
 +# define YY_DECL \
 +  yy::calcxx_parser::symbol_type yylex (calcxx_driver& driver)
  // ... and declare it for the parser's sake.
  YY_DECL;
  @end example
@@@ -10134,8 -9554,8 +10144,8 @@@ public
  @end example
  
  @noindent
 -To encapsulate the coordination with the Flex scanner, it is useful to
 -have two members function to open and close the scanning phase.
 +To encapsulate the coordination with the Flex scanner, it is useful to have
 +member functions to open and close the scanning phase.
  
  @comment file: calc++-driver.hh
  @example
@@@ -10150,13 -9570,9 +10160,13 @@@ Similarly for the parser itself
  
  @comment file: calc++-driver.hh
  @example
 -  // Run the parser.  Return 0 on success.
 +  // Run the parser on file F.
 +  // Return 0 on success.
    int parse (const std::string& f);
 +  // The name of the file being parsed.
 +  // Used later to pass the file name to the location tracker.
    std::string file;
 +  // Whether parser traces should be generated.
    bool trace_parsing;
  @end example
  
@@@ -10238,35 -9654,19 +10248,35 @@@ the grammar for
  %define parser_class_name "calcxx_parser"
  @end example
  
 +@noindent
 +@findex %define variant
 +@findex %define lex_symbol
 +This example will use genuine C++ objects as semantic values, therefore, we
 +require the variant-based interface.  To make sure we properly use it, we
 +enable assertions.  To fully benefit from type-safety and more natural
 +definition of ``symbol'', we enable @code{lex_symbol}.
 +
 +@comment file: calc++-parser.yy
 +@example
 +%define variant
 +%define parse.assert
 +%define lex_symbol
 +@end example
 +
  @noindent
  @findex %code requires
 -Then come the declarations/inclusions needed to define the
 -@code{%union}.  Because the parser uses the parsing driver and
 -reciprocally, both cannot include the header of the other.  Because the
 +Then come the declarations/inclusions needed by the semantic values.
 +Because the parser uses the parsing driver and reciprocally, both would like
 +to include the header of the other, which is, of course, insane.  This
 +mutual dependency will be broken using forward declarations.  Because the
  driver's header needs detailed knowledge about the parser class (in
 -particular its inner types), it is the parser's header which will simply
 -use a forward declaration of the driver.
 -@xref{%code Summary}.
 +particular its inner types), it is the parser's header which will use a
 +forward declaration of the driver.  @xref{%code Summary}.
  
  @comment file: calc++-parser.yy
  @example
 -%code requires @{
 +%code requires
 +@{
  # include <string>
  class calcxx_driver;
  @}
@@@ -10280,14 -9680,15 +10290,14 @@@ global variables
  @comment file: calc++-parser.yy
  @example
  // The parsing context.
 -%parse-param @{ calcxx_driver& driver @}
 -%lex-param   @{ calcxx_driver& driver @}
 +%param @{ calcxx_driver& driver @}
  @end example
  
  @noindent
 -Then we request the location tracking feature, and initialize the
 +Then we request location tracking, and initialize the
  first location's file name.  Afterward new locations are computed
  relatively to the previous locations: the file name will be
 -automatically propagated.
 +propagated.
  
  @comment file: calc++-parser.yy
  @example
  @end example
  
  @noindent
 -Use the two following directives to enable parser tracing and verbose error
 +Use the following two directives to enable parser tracing and verbose error
  messages.  However, verbose error messages can contain incorrect information
  (@pxref{LAC}).
  
  @comment file: calc++-parser.yy
  @example
 -%debug
 -%error-verbose
 -@end example
 -
 -@noindent
 -Semantic values cannot use ``real'' objects, but only pointers to
 -them.
 -
 -@comment file: calc++-parser.yy
 -@example
 -// Symbols.
 -%union
 -@{
 -  int          ival;
 -  std::string *sval;
 -@};
 +%define parse.trace
 +%define parse.error verbose
  @end example
  
  @noindent
@@@ -10317,8 -9732,7 +10327,8 @@@ The code between @samp{%code @{} and @s
  
  @comment file: calc++-parser.yy
  @example
 -%code @{
 +%code
 +@{
  # include "calc++-driver.hh"
  @}
  @end example
  
  @noindent
  The token numbered as 0 corresponds to end of file; the following line
 -allows for nicer error messages referring to ``end of file'' instead
 -of ``$end''.  Similarly user friendly named are provided for each
 -symbol.  Note that the tokens names are prefixed by @code{TOKEN_} to
 -avoid name clashes.
 +allows for nicer error messages referring to ``end of file'' instead of
 +``$end''.  Similarly user friendly names are provided for each symbol.  To
 +avoid name clashes in the generated files (@pxref{Calc++ Scanner}), prefix
 +tokens with @code{TOK_} (@pxref{%define Summary,,api.tokens.prefix}).
  
  @comment file: calc++-parser.yy
  @example
 -%token        END      0 "end of file"
 -%token        ASSIGN     ":="
 -%token <sval> IDENTIFIER "identifier"
 -%token <ival> NUMBER     "number"
 -%type  <ival> exp
 +%define api.tokens.prefix "TOK_"
 +%token
 +  END  0  "end of file"
 +  ASSIGN  ":="
 +  MINUS   "-"
 +  PLUS    "+"
 +  STAR    "*"
 +  SLASH   "/"
 +  LPAREN  "("
 +  RPAREN  ")"
 +;
  @end example
  
  @noindent
 -To enable memory deallocation during error recovery, use
 -@code{%destructor}.
 +Since we use variant-based semantic values, @code{%union} is not used, and
 +both @code{%type} and @code{%token} expect genuine types, as opposed to type
 +tags.
  
 -@c FIXME: Document %printer, and mention that it takes a braced-code operand.
  @comment file: calc++-parser.yy
  @example
 -%printer    @{ yyoutput << *$$; @} "identifier"
 -%destructor @{ delete $$; @} "identifier"
 +%token <std::string> IDENTIFIER "identifier"
 +%token <int> NUMBER "number"
 +%type  <int> exp
 +@end example
 +
 +@noindent
 +No @code{%destructor} is needed to enable memory deallocation during error
 +recovery; the memory, for strings for instance, will be reclaimed by the
 +regular destructors.  All the values are printed using their
 +@code{operator<<} (@pxref{Printer Decl, , Printing Semantic Values}).
  
 -%printer    @{ yyoutput << $$; @} <ival>
 +@comment file: calc++-parser.yy
 +@example
 +%printer @{ yyoutput << $$; @} <*>;
  @end example
  
  @noindent
 -The grammar itself is straightforward.
 +The grammar itself is straightforward (@pxref{Location Tracking Calc, ,
 +Location Tracking Calculator: @code{ltcalc}}).
  
  @comment file: calc++-parser.yy
  @example
@@@ -10384,18 -9781,17 +10394,18 @@@ assignments
  | assignments assignment @{@};
  
  assignment:
 -     "identifier" ":=" exp
 -       @{ driver.variables[*$1] = $3; delete $1; @};
 -
 -%left '+' '-';
 -%left '*' '/';
 -exp: exp '+' exp   @{ $$ = $1 + $3; @}
 -   | exp '-' exp   @{ $$ = $1 - $3; @}
 -   | exp '*' exp   @{ $$ = $1 * $3; @}
 -   | exp '/' exp   @{ $$ = $1 / $3; @}
 -   | "identifier"  @{ $$ = driver.variables[*$1]; delete $1; @}
 -   | "number"      @{ $$ = $1; @};
 +  "identifier" ":=" exp @{ driver.variables[$1] = $3; @};
 +
 +%left "+" "-";
 +%left "*" "/";
 +exp:
 +  exp "+" exp   @{ $$ = $1 + $3; @}
 +| exp "-" exp   @{ $$ = $1 - $3; @}
 +| exp "*" exp   @{ $$ = $1 * $3; @}
 +| exp "/" exp   @{ $$ = $1 / $3; @}
 +| "(" exp ")"   @{ std::swap ($$, $2); @}
 +| "identifier"  @{ $$ = driver.variables[$1]; @}
 +| "number"      @{ std::swap ($$, $1); @};
  %%
  @end example
  
@@@ -10406,7 -9802,7 +10416,7 @@@ driver
  @comment file: calc++-parser.yy
  @example
  void
 -yy::calcxx_parser::error (const yy::calcxx_parser::location_type& l,
 +yy::calcxx_parser::error (const location_type& l,
                            const std::string& m)
  @{
    driver.error (l, m);
@@@ -10422,22 -9818,24 +10432,22 @@@ parser's to get the set of defined toke
  @comment file: calc++-scanner.ll
  @example
  %@{ /* -*- C++ -*- */
 -# include <cstdlib>
  # include <cerrno>
  # include <climits>
 +# include <cstdlib>
  # include <string>
  # include "calc++-driver.hh"
  # include "calc++-parser.hh"
  
 -/* Work around an incompatibility in flex (at least versions
 -   2.5.31 through 2.5.33): it generates code that does
 -   not conform to C89.  See Debian bug 333231
 -   <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>.  */
 +// Work around an incompatibility in flex (at least versions
 +// 2.5.31 through 2.5.33): it generates code that does
 +// not conform to C89.  See Debian bug 333231
 +// <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333231>.
  # undef yywrap
  # define yywrap() 1
  
 -/* By default yylex returns int, we use token_type.
 -   Unfortunately yyterminate by default returns 0, which is
 -   not of token_type.  */
 -#define yyterminate() return token::END
 +// The location of the current token.
 +static yy::location loc;
  %@}
  @end example
  
  Because there is no @code{#include}-like feature we don't need
  @code{yywrap}, we don't need @code{unput} either, and we parse an
  actual file, this is not an interactive session with the user.
 -Finally we enable the scanner tracing features.
 +Finally, we enable scanner tracing.
  
  @comment file: calc++-scanner.ll
  @example
@@@ -10465,8 -9863,8 +10475,8 @@@ blank [ \t
  @noindent
  The following paragraph suffices to track locations accurately.  Each
  time @code{yylex} is invoked, the begin position is moved onto the end
 -position.  Then when a pattern is matched, the end position is
 -advanced of its width.  In case it matched ends of lines, the end
 +position.  Then when a pattern is matched, its width is added to the end
 +column.  When matching ends of lines, the end
  cursor is adjusted, and each time blanks are matched, the begin cursor
  is moved onto the end cursor to effectively ignore the blanks
  preceding tokens.  Comments would be treated equally.
  @example
  @group
  %@{
 -# define YY_USER_ACTION  yylloc->columns (yyleng);
 +  // Code run each time a pattern is matched.
 +  # define YY_USER_ACTION  loc.columns (yyleng);
  %@}
  @end group
  %%
 +@group
  %@{
 -  yylloc->step ();
 +  // Code run each time yylex is called.
 +  loc.step ();
  %@}
 -@{blank@}+   yylloc->step ();
 -[\n]+      yylloc->lines (yyleng); yylloc->step ();
 +@end group
 +@{blank@}+   loc.step ();
 +[\n]+      loc.lines (yyleng); loc.step ();
  @end example
  
  @noindent
 -The rules are simple, just note the use of the driver to report errors.
 -It is convenient to use a typedef to shorten
 -@code{yy::calcxx_parser::token::identifier} into
 -@code{token::identifier} for instance.
 +The rules are simple.  The driver is used to report errors.
  
  @comment file: calc++-scanner.ll
  @example
 -%@{
 -  typedef yy::calcxx_parser::token token;
 -%@}
 -           /* Convert ints to the actual type of tokens.  */
 -[-+*/]     return yy::calcxx_parser::token_type (yytext[0]);
 -":="       return token::ASSIGN;
 +"-"      return yy::calcxx_parser::make_MINUS(loc);
 +"+"      return yy::calcxx_parser::make_PLUS(loc);
 +"*"      return yy::calcxx_parser::make_STAR(loc);
 +"/"      return yy::calcxx_parser::make_SLASH(loc);
 +"("      return yy::calcxx_parser::make_LPAREN(loc);
 +")"      return yy::calcxx_parser::make_RPAREN(loc);
 +":="     return yy::calcxx_parser::make_ASSIGN(loc);
 +
 +@group
  @{int@}      @{
    errno = 0;
    long n = strtol (yytext, NULL, 10);
    if (! (INT_MIN <= n && n <= INT_MAX && errno != ERANGE))
 -    driver.error (*yylloc, "integer is out of range");
 -  yylval->ival = n;
 -  return token::NUMBER;
 +    driver.error (loc, "integer is out of range");
 +  return yy::calcxx_parser::make_NUMBER(n, loc);
  @}
 -@{id@}       yylval->sval = new std::string (yytext); return token::IDENTIFIER;
 -.          driver.error (*yylloc, "invalid character");
 +@end group
 +@{id@}       return yy::calcxx_parser::make_IDENTIFIER(yytext, loc);
 +.          driver.error (loc, "invalid character");
 +<<EOF>>    return yy::calcxx_parser::make_END(loc);
  %%
  @end example
  
  @noindent
 -Finally, because the scanner related driver's member function depend
 +Finally, because the scanner-related driver's member-functions depend
  on the scanner's data, it is simpler to implement them in this file.
  
  @comment file: calc++-scanner.ll
@@@ -10562,7 -9955,6 +10572,7 @@@ The top level file, @file{calc++.cc}, p
  int
  main (int argc, char *argv[])
  @{
 +  int res = 0;
    calcxx_driver driver;
    for (int i = 1; i < argc; ++i)
      if (argv[i] == std::string ("-p"))
        driver.trace_scanning = true;
      else if (!driver.parse (argv[i]))
        std::cout << driver.result << std::endl;
 +    else
 +      res = 1;
 +  return res;
  @}
  @end group
  @end example
@@@ -10618,7 -10007,7 +10628,7 @@@ You can create documentation for genera
  Contrary to C parsers, Java parsers do not use global variables; the
  state of the parser is always local to an instance of the parser class.
  Therefore, all Java parsers are ``pure'', and the @code{%pure-parser}
 -and @code{%define api.pure} directives does not do anything when used in
 +and @samp{%define api.pure} directives does not do anything when used in
  Java.
  
  Push parsers are currently unsupported in Java and @code{%define
@@@ -10631,23 -10020,15 +10641,23 @@@ No header file can be generated for Jav
  @code{%defines} directive or the @option{-d}/@option{--defines} options.
  
  @c FIXME: Possible code change.
 -Currently, support for debugging and verbose errors are always compiled
 -in.  Thus the @code{%debug} and @code{%token-table} directives and the
 +Currently, support for tracing is always compiled
 +in.  Thus the @samp{%define parse.trace} and @samp{%token-table}
 +directives and the
  @option{-t}/@option{--debug} and @option{-k}/@option{--token-table}
  options have no effect.  This may change in the future to eliminate
 -unused code in the generated parser, so use @code{%debug} and
 -@code{%verbose-error} explicitly if needed.  Also, in the future the
 +unused code in the generated parser, so use @samp{%define parse.trace}
 +explicitly
 +if needed.  Also, in the future the
  @code{%token-table} directive might enable a public interface to
  access the token names and codes.
  
 +Getting a ``code too large'' error from the Java compiler means the code
 +hit the 64KB bytecode per method limitation of the Java class file.
 +Try reducing the amount of code in actions and static initializers;
 +otherwise, report a bug so that the parser skeleton will be improved.
 +
 +
  @node Java Semantic Values
  @subsection Java Semantic Values
  @c - No %union, specify type in %type/%token.
@@@ -10666,7 -10047,7 +10676,7 @@@ semantic values' types (class names) sh
  By default, the semantic stack is declared to have @code{Object} members,
  which means that the class types you specify can be of any class.
  To improve the type safety of the parser, you can declare the common
 -superclass of all the semantic values using the @code{%define stype}
 +superclass of all the semantic values using the @samp{%define stype}
  directive.  For example, after the following declaration:
  
  @example
@@@ -10705,11 -10086,11 +10715,11 @@@ class defines a @dfn{position}, a singl
  defines a class representing a @dfn{location}, a range composed of a pair of
  positions (possibly spanning several files).  The location class is an inner
  class of the parser; the name is @code{Location} by default, and may also be
 -renamed using @code{%define location_type "@var{class-name}"}.
 +renamed using @samp{%define location_type "@var{class-name}"}.
  
  The location class treats the position as a completely opaque value.
  By default, the class name is @code{Position}, but this can be changed
 -with @code{%define position_type "@var{class-name}"}.  This class must
 +with @samp{%define position_type "@var{class-name}"}.  This class must
  be supplied by the user.
  
  
@@@ -10744,22 -10125,20 +10754,22 @@@ properly, the position class should ove
  The name of the generated parser class defaults to @code{YYParser}.  The
  @code{YY} prefix may be changed using the @code{%name-prefix} directive
  or the @option{-p}/@option{--name-prefix} option.  Alternatively, use
 -@code{%define parser_class_name "@var{name}"} to give a custom name to
 +@samp{%define parser_class_name "@var{name}"} to give a custom name to
  the class.  The interface of this class is detailed below.
  
  By default, the parser class has package visibility.  A declaration
 -@code{%define public} will change to public visibility.  Remember that,
 +@samp{%define public} will change to public visibility.  Remember that,
  according to the Java language specification, the name of the @file{.java}
  file should match the name of the class in this case.  Similarly, you can
  use @code{abstract}, @code{final} and @code{strictfp} with the
  @code{%define} declaration to add other modifiers to the parser class.
 +A single @samp{%define annotations "@var{annotations}"} directive can
 +be used to add any number of annotations to the parser class.
  
  The Java package name of the parser class can be specified using the
 -@code{%define package} directive.  The superclass and the implemented
 +@samp{%define package} directive.  The superclass and the implemented
  interfaces of the parser class can be specified with the @code{%define
 -extends} and @code{%define implements} directives.
 +extends} and @samp{%define implements} directives.
  
  The parser class defines an inner class, @code{Location}, that is used
  for location tracking (see @ref{Java Location Values}), and a inner
@@@ -10768,33 -10147,30 +10778,33 @@@ these inner class/interface, and the me
  below, all the other members and fields are preceded with a @code{yy} or
  @code{YY} prefix to avoid clashes with user code.
  
 -@c FIXME: The following constants and variables are still undocumented:
 -@c @code{bisonVersion}, @code{bisonSkeleton} and @code{errorVerbose}.
 -
  The parser class can be extended using the @code{%parse-param}
  directive. Each occurrence of the directive will add a @code{protected
  final} field to the parser class, and an argument to its constructor,
  which initialize them automatically.
  
 -Token names defined by @code{%token} and the predefined @code{EOF} token
 -name are added as constant fields to the parser class.
 -
  @deftypeop {Constructor} {YYParser} {} YYParser (@var{lex_param}, @dots{}, @var{parse_param}, @dots{})
  Build a new parser object with embedded @code{%code lexer}.  There are
 -no parameters, unless @code{%parse-param}s and/or @code{%lex-param}s are
 -used.
 +no parameters, unless @code{%param}s and/or @code{%parse-param}s and/or
 +@code{%lex-param}s are used.
 +
 +Use @code{%code init} for code added to the start of the constructor
 +body. This is especially useful to initialize superclasses. Use
 +@samp{%define init_throws} to specify any uncaught exceptions.
  @end deftypeop
  
  @deftypeop {Constructor} {YYParser} {} YYParser (Lexer @var{lexer}, @var{parse_param}, @dots{})
  Build a new parser object using the specified scanner.  There are no
 -additional parameters unless @code{%parse-param}s are used.
 +additional parameters unless @code{%param}s and/or @code{%parse-param}s are
 +used.
  
  If the scanner is defined by @code{%code lexer}, this constructor is
  declared @code{protected} and is called automatically with a scanner
 -created with the correct @code{%lex-param}s.
 +created with the correct @code{%param}s and/or @code{%lex-param}s.
 +
 +Use @code{%code init} for code added to the start of the constructor
 +body. This is especially useful to initialize superclasses. Use
 +@samp{%define init_throws} to specify any uncaught exceptions.
  @end deftypeop
  
  @deftypemethod {YYParser} {boolean} parse ()
@@@ -10802,21 -10178,6 +10812,21 @@@ Run the syntactic analysis, and return 
  @code{false} otherwise.
  @end deftypemethod
  
 +@deftypemethod {YYParser} {boolean} getErrorVerbose ()
 +@deftypemethodx {YYParser} {void} setErrorVerbose (boolean @var{verbose})
 +Get or set the option to produce verbose error messages.  These are only
 +available with @samp{%define parse.error verbose}, which also turns on
 +verbose error messages.
 +@end deftypemethod
 +
 +@deftypemethod {YYParser} {void} yyerror (String @var{msg})
 +@deftypemethodx {YYParser} {void} yyerror (Position @var{pos}, String @var{msg})
 +@deftypemethodx {YYParser} {void} yyerror (Location @var{loc}, String @var{msg})
 +Print an error message using the @code{yyerror} method of the scanner
 +instance in use. The @code{Location} and @code{Position} parameters are
 +available only if location tracking is active.
 +@end deftypemethod
 +
  @deftypemethod {YYParser} {boolean} recovering ()
  During the syntactic analysis, return @code{true} if recovering
  from a syntax error.
@@@ -10835,11 -10196,6 +10845,11 @@@ Get or set the tracing level.  Currentl
  or nonzero, full tracing.
  @end deftypemethod
  
 +@deftypecv {Constant} {YYParser} {String} {bisonVersion}
 +@deftypecvx {Constant} {YYParser} {String} {bisonSkeleton}
 +Identify the Bison version and skeleton used to generate this parser.
 +@end deftypecv
 +
  
  @node Java Scanner Interface
  @subsection Java Scanner Interface
  There are two possible ways to interface a Bison-generated Java parser
  with a scanner: the scanner may be defined by @code{%code lexer}, or
  defined elsewhere.  In either case, the scanner has to implement the
 -@code{Lexer} inner interface of the parser class.
 +@code{Lexer} inner interface of the parser class.  This interface also
 +contain constants for all user-defined token names and the predefined
 +@code{EOF} token.
  
  In the first case, the body of the scanner class is placed in
  @code{%code lexer} blocks.  If you want to pass parameters from the
@@@ -10871,7 -10225,7 +10881,7 @@@ In both cases, the scanner has to imple
  @deftypemethod {Lexer} {void} yyerror (Location @var{loc}, String @var{msg})
  This method is defined by the user to emit an error message.  The first
  parameter is omitted if location tracking is not active.  Its type can be
 -changed using @code{%define location_type "@var{class-name}".}
 +changed using @samp{%define location_type "@var{class-name}".}
  @end deftypemethod
  
  @deftypemethod {Lexer} {int} yylex ()
@@@ -10879,7 -10233,7 +10889,7 @@@ Return the next token.  Its type is th
  value and location are saved and returned by the their methods in the
  interface.
  
 -Use @code{%define lex_throws} to specify any uncaught exceptions.
 +Use @samp{%define lex_throws} to specify any uncaught exceptions.
  Default is @code{java.io.IOException}.
  @end deftypemethod
  
@@@ -10889,14 -10243,14 +10899,14 @@@ Return respectively the first position 
  @code{yylex} returned, and the first position beyond it.  These
  methods are not needed unless location tracking is active.
  
 -The return type can be changed using @code{%define position_type
 +The return type can be changed using @samp{%define position_type
  "@var{class-name}".}
  @end deftypemethod
  
  @deftypemethod {Lexer} {Object} getLVal ()
  Return the semantic value of the last token that yylex returned.
  
 -The return type can be changed using @code{%define stype
 +The return type can be changed using @samp{%define stype
  "@var{class-name}".}
  @end deftypemethod
  
  The following special constructs can be uses in Java actions.
  Other analogous C action features are currently unavailable for Java.
  
 -Use @code{%define throws} to specify any uncaught exceptions from parser
 +Use @samp{%define throws} to specify any uncaught exceptions from parser
  actions, and initial actions specified by @code{%initial-action}.
  
  @defvar $@var{n}
@@@ -10924,7 -10278,7 +10934,7 @@@ Like @code{$@var{n}} but specifies a al
  @defvar $$
  The semantic value for the grouping made by the current rule.  As a
  value, this is in the base type (@code{Object} or as specified by
 -@code{%define stype}) as in not cast to the declared subtype because
 +@samp{%define stype}) as in not cast to the declared subtype because
  casts are not allowed on the left-hand side of Java assignments.
  Use an explicit Java cast if the correct subtype is needed.
  @xref{Java Semantic Values}.
@@@ -10971,12 -10325,11 +10981,12 @@@ operation
  @xref{Error Recovery}.
  @end deftypefn
  
 -@deftypefn  {Function} {protected void} yyerror (String msg)
 -@deftypefnx {Function} {protected void} yyerror (Position pos, String msg)
 -@deftypefnx {Function} {protected void} yyerror (Location loc, String msg)
 +@deftypefn  {Function} {void} yyerror (String @var{msg})
 +@deftypefnx {Function} {void} yyerror (Position @var{loc}, String @var{msg})
 +@deftypefnx {Function} {void} yyerror (Location @var{loc}, String @var{msg})
  Print an error message using the @code{yyerror} method of the scanner
 -instance in use.
 +instance in use. The @code{Location} and @code{Position} parameters are
 +available only if location tracking is active.
  @end deftypefn
  
  
@@@ -11020,7 -10373,7 +11030,7 @@@ The prologue declarations have a differ
  @item @code{%code imports}
  blocks are placed at the beginning of the Java source code.  They may
  include copyright notices.  For a @code{package} declarations, it is
 -suggested to use @code{%define package} instead.
 +suggested to use @samp{%define package} instead.
  
  @item unqualified @code{%code}
  blocks are placed inside the parser class.
@@@ -11061,7 -10414,7 +11071,7 @@@ constructor that @emph{creates} a lexer
  
  @deffn {Directive} %name-prefix "@var{prefix}"
  The prefix of the parser class name @code{@var{prefix}Parser} if
 -@code{%define parser_class_name} is not used.  Default is @code{YY}.
 +@samp{%define parser_class_name} is not used.  Default is @code{YY}.
  @xref{Java Bison Interface}.
  @end deffn
  
@@@ -11092,11 -10445,6 +11102,11 @@@ Code inserted just after the @code{pack
  @xref{Java Differences}.
  @end deffn
  
 +@deffn {Directive} {%code init} @{ @var{code} @dots{} @}
 +Code inserted at the beginning of the parser constructor body.
 +@xref{Java Parser Interface}.
 +@end deffn
 +
  @deffn {Directive} {%code lexer} @{ @var{code} @dots{} @}
  Code added to the body of a inner lexer class within the parser class.
  @xref{Java Scanner Interface}.
@@@ -11109,7 -10457,7 +11119,7 @@@ Code (after the second @code{%%}) appen
  @end deffn
  
  @deffn {Directive} %@{ @var{code} @dots{} %@}
 -Not supported.  Use @code{%code import} instead.
 +Not supported.  Use @code{%code imports} instead.
  @xref{Java Differences}.
  @end deffn
  
@@@ -11118,11 -10466,6 +11128,11 @@@ Whether the parser class is declared @c
  @xref{Java Bison Interface}.
  @end deffn
  
 +@deffn {Directive} {%define annotations} "@var{annotations}"
 +The Java annotations for the parser class.  Default is none.
 +@xref{Java Bison Interface}.
 +@end deffn
 +
  @deffn {Directive} {%define extends} "@var{superclass}"
  The superclass of the parser class.  Default is none.
  @xref{Java Bison Interface}.
@@@ -11139,12 -10482,6 +11149,12 @@@ Default is none
  @xref{Java Bison Interface}.
  @end deffn
  
 +@deffn {Directive} {%define init_throws} "@var{exceptions}"
 +The exceptions thrown by @code{%code init} from the parser class
 +constructor.  Default is none.
 +@xref{Java Parser Interface}.
 +@end deffn
 +
  @deffn {Directive} {%define lex_throws} "@var{exceptions}"
  The exceptions thrown by the @code{yylex} method of the lexer, a
  comma-separated list.  Default is @code{java.io.IOException}.
@@@ -11662,19 -10999,6 +11672,19 @@@ the grammar file.  @xref{Grammar Outlin
  Grammar}.
  @end deffn
  
 +@deffn {Directive} %?@{@var{expression}@}
 +Predicate actions.  This is a type of action clause that may appear in
 +rules. The expression is evaluated, and if false, causes a syntax error.  In
 +GLR parsers during nondeterministic operation,
 +this silently causes an alternative parse to die.  During deterministic
 +operation, it is the same as the effect of YYERROR.
 +@xref{Semantic Predicates}.
 +
 +This feature is experimental.
 +More user feedback will help to determine whether it should become a permanent
 +feature.
 +@end deffn
 +
  @deffn {Construct} /*@dots{}*/
  Comment delimiters, as in C.
  @end deffn
@@@ -11784,8 -11108,8 +11794,8 @@@ token is reset to the token that origin
  @end deffn
  
  @deffn {Directive} %error-verbose
 -Bison declaration to request verbose, specific error message strings
 -when @code{yyerror} is called.  @xref{Error Reporting}.
 +An obsolete directive standing for @samp{%define parse.error verbose}
 +(@pxref{Error Reporting, ,The Error Reporting Function @code{yyerror}}).
  @end deffn
  
  @deffn {Directive} %file-prefix "@var{prefix}"
@@@ -11808,12 -11132,12 +11818,12 @@@ Specify the programming language for th
  @end deffn
  
  @deffn {Directive} %left
 -Bison declaration to assign left associativity to token(s).
 +Bison declaration to assign precedence and left associativity to token(s).
  @xref{Precedence Decl, ,Operator Precedence}.
  @end deffn
  
 -@deffn {Directive} %lex-param @{@var{argument-declaration}@}
 -Bison declaration to specifying an additional parameter that
 +@deffn {Directive} %lex-param @{@var{argument-declaration}@} @dots{}
 +Bison declaration to specifying additional arguments that
  @code{yylex} should accept.  @xref{Pure Calling,, Calling Conventions
  for Pure Parsers}.
  @end deffn
@@@ -11858,7 -11182,7 +11868,7 @@@ parser implementation file.  @xref{Dec
  @end deffn
  
  @deffn {Directive} %nonassoc
 -Bison declaration to assign nonassociativity to token(s).
 +Bison declaration to assign precedence and nonassociativity to token(s).
  @xref{Precedence Decl, ,Operator Precedence}.
  @end deffn
  
@@@ -11867,15 -11191,10 +11877,15 @@@ Bison declaration to set the name of th
  @xref{Decl Summary}.
  @end deffn
  
 -@deffn {Directive} %parse-param @{@var{argument-declaration}@}
 -Bison declaration to specifying an additional parameter that
 -@code{yyparse} should accept.  @xref{Parser Function,, The Parser
 -Function @code{yyparse}}.
 +@deffn {Directive} %param @{@var{argument-declaration}@} @dots{}
 +Bison declaration to specify additional arguments that both
 +@code{yylex} and @code{yyparse} should accept.  @xref{Parser Function,, The
 +Parser Function @code{yyparse}}.
 +@end deffn
 +
 +@deffn {Directive} %parse-param @{@var{argument-declaration}@} @dots{}
 +Bison declaration to specify additional arguments that @code{yyparse}
 +should accept.  @xref{Parser Function,, The Parser Function @code{yyparse}}.
  @end deffn
  
  @deffn {Directive} %prec
@@@ -11883,13 -11202,8 +11893,13 @@@ Bison declaration to assign a precedenc
  @xref{Contextual Precedence, ,Context-Dependent Precedence}.
  @end deffn
  
 +@deffn {Directive} %precedence
 +Bison declaration to assign precedence to token(s), but no associativity
 +@xref{Precedence Decl, ,Operator Precedence}.
 +@end deffn
 +
  @deffn {Directive} %pure-parser
 -Deprecated version of @code{%define api.pure} (@pxref{%define
 +Deprecated version of @samp{%define api.pure} (@pxref{%define
  Summary,,api.pure}), for which Bison is more careful to warn about
  unreasonable usage.
  @end deffn
@@@ -11900,7 -11214,7 +11910,7 @@@ Require a Version of Bison}
  @end deffn
  
  @deffn {Directive} %right
 -Bison declaration to assign right associativity to token(s).
 +Bison declaration to assign precedence and right associativity to token(s).
  @xref{Precedence Decl, ,Operator Precedence}.
  @end deffn
  
@@@ -12005,16 -11319,17 +12015,16 @@@ instead
  
  @deffn {Function} yyerror
  User-supplied function to be called by @code{yyparse} on error.
 -@xref{Error Reporting, ,The Error
 -Reporting Function @code{yyerror}}.
 +@xref{Error Reporting, ,The Error Reporting Function @code{yyerror}}.
  @end deffn
  
  @deffn {Macro} YYERROR_VERBOSE
 -An obsolete macro that you define with @code{#define} in the prologue
 -to request verbose, specific error message strings
 -when @code{yyerror} is called.  It doesn't matter what definition you
 -use for @code{YYERROR_VERBOSE}, just whether you define it.
 -Supported by the C skeletons only; using
 -@code{%error-verbose} is preferred.  @xref{Error Reporting}.
 +An obsolete macro used in the @file{yacc.c} skeleton, that you define
 +with @code{#define} in the prologue to request verbose, specific error
 +message strings when @code{yyerror} is called.  It doesn't matter what
 +definition you use for @code{YYERROR_VERBOSE}, just whether you define
 +it.  Using @samp{%define parse.error verbose} is preferred
 +(@pxref{Error Reporting, ,The Error Reporting Function @code{yyerror}}).
  @end deffn
  
  @deffn {Macro} YYFPRINTF
@@@ -12125,6 -11440,13 +12135,6 @@@ parse a single token.  @xref{Push Parse
  More user feedback will help to stabilize it.)
  @end deffn
  
 -@deffn {Macro} YYPARSE_PARAM
 -An obsolete macro for specifying the name of a parameter that
 -@code{yyparse} should accept.  The use of this macro is deprecated, and
 -is supported only for Yacc like parsers.  @xref{Pure Calling,, Calling
 -Conventions for Pure Parsers}.
 -@end deffn
 -
  @deffn {Macro} YYRECOVERING
  The expression @code{YYRECOVERING ()} yields 1 when the parser
  is recovering from a syntax error, and 0 otherwise.
diff --combined tests/headers.at
index df0c0580563a0ed11274f14f5157ecb6b85c12f3,8e70a7eb4f347cd556dbfcd1b4996e90eec4d373..73095ce0db087aa5435a18b88f93a5cd22330e56
@@@ -127,7 -127,8 +127,8 @@@ AT_SETUP([Several parsers]
  # AT_TEST([PREFIX], [DIRECTIVES])
  # -------------------------------
  # Generate and compile to *.o.  Make sure there is no (allowed) YY*
- # nor yy* identifiers in the header.
+ # nor yy* identifiers in the header.  Check that headers are
+ # self-contained, and can be compiled by a C++ compiler.
  m4_pushdef([AT_TEST],
  [AT_BISON_OPTION_PUSHDEFS([%define api.prefix "$1_" $2])
  AT_DATA_GRAMMAR([$1.AT_SKEL_CC_IF([yy], [y])],
@@@ -168,14 -169,13 +169,14 @@@ AT_SKEL_CC_IF([]
    [AT_CHECK([$EGREP yy $1.h], [1])])
  
  # Check there is not 'YY' left.
 -# Ignore comments, YYPARSE_PARAM (obsolete), YYPUSH_MORE(_DEFINED)?
 -# (constant definition), YY_\w+_INCLUDED (header guards).
 +# Ignore comments, YYPUSH_MORE(_DEFINED)?  (constant definition),
 +# YY_\w+_INCLUDED (header guards).
  #
  # YYDEBUG (not renamed) can be read, but not changed.
 -AT_CHECK([[sed -ne 's,/\*[^*]*\*/,,g;s,//.*,,' \
 -                -e '/YY/p' ]$1.AT_SKEL_CC_IF([hh], [h])[ |
 -     $EGREP -wv 'YY(PARSE_PARAM|PUSH_MORE(_DEFINED)?|_[0-9A-Z_]+_INCLUDED)|(defined|if) YYDEBUG']],
 +AT_CHECK([[$PERL -0777 -e 's{/\*.*?\*/}{}sg;s,//.*,,;' \
 +            ]$1.AT_SKEL_CC_IF([hh], [h])[ |
 +         grep 'YY' |
 +     $EGREP -wv 'YY(PUSH_MORE(_DEFINED)?|_[0-9A-Z_]+_INCLUDED)|(defined|if) YYDEBUG']],
           [1])
  
  AT_LANG_COMPILE([$1.o])
@@@ -243,6 -243,19 +244,19 @@@ AT_TEST([x8], [%define api.pure %defin
  AT_COMPILE_CXX([parser], [[x[1-8].o -DCC_IS_CXX=$CC_IS_CXX main.cc]])
  AT_CHECK([./parser], [0], [[expout]])
  
+ # Check that the headers are self-contained, and protected against
+ # multiple inclusions.  While at it, check they are sane for C++.
+ for h in *.h *.hh
+ do
+   # No shell expansion with AT_DATA.
+   cat >$h.cc <<EOF
+ AT_DATA_SOURCE_PROLOGUE
+ #include "$h"
+ #include "$h"
+ EOF
+   AT_COMPILE_CXX([$h.o])
+ done
  m4_popdef([AT_TEST])
  
  AT_CLEANUP