+ In the more common case, explicit names may be declared:
+
+ stmt[res] : "if" expr[cond] "then" stmt[then] "else" stmt[else] ';'
+ { $res = mk_if_stmt($cond, $then, $else); }
+
+ Location information is also accessible using @name syntax. When
+ accessing symbol names containing dots or dashes, explicit bracketing
+ ($[sym.1]) must be used.
+
+ These features are experimental in this version. More user feedback
+ will help to stabilize them.
+
+** IELR(1) and canonical LR(1):
+
+ IELR(1) is a minimal LR(1) parser table generation algorithm. That
+ is, given any context-free grammar, IELR(1) generates parser tables
+ with the full language-recognition power of canonical LR(1) but with
+ nearly the same number of parser states as LALR(1). This reduction
+ in parser states is often an order of magnitude. More importantly,
+ because canonical LR(1)'s extra parser states may contain duplicate
+ conflicts in the case of non-LR(1) grammars, the number of conflicts
+ for IELR(1) is often an order of magnitude less as well. This can
+ significantly reduce the complexity of developing of a grammar.
+
+ Bison can now generate IELR(1) and canonical LR(1) parser tables in
+ place of its traditional LALR(1) parser tables, which remain the
+ default. You can specify the type of parser tables in the grammar
+ file with these directives:
+
+ %define lr.type lalr
+ %define lr.type ielr
+ %define lr.type canonical-lr
+
+ The default-reduction optimization in the parser tables can also be
+ adjusted using `%define lr.default-reductions'. For details on both
+ of these features, see the new section `Tuning LR' in the Bison
+ manual.
+
+ These features are experimental. More user feedback will help to
+ stabilize them.
+
+** LAC (Lookahead Correction) for syntax error handling:
+
+ Canonical LR, IELR, and LALR can suffer from a couple of problems
+ upon encountering a syntax error. First, the parser might perform
+ additional parser stack reductions before discovering the syntax
+ error. Such reductions can perform user semantic actions that are
+ unexpected because they are based on an invalid token, and they
+ cause error recovery to begin in a different syntactic context than
+ the one in which the invalid token was encountered. Second, when
+ verbose error messages are enabled (with %error-verbose or the
+ obsolete `#define YYERROR_VERBOSE'), the expected token list in the
+ syntax error message can both contain invalid tokens and omit valid
+ tokens.
+
+ The culprits for the above problems are %nonassoc, default
+ reductions in inconsistent states, and parser state merging. Thus,
+ IELR and LALR suffer the most. Canonical LR can suffer only if
+ %nonassoc is used or if default reductions are enabled for
+ inconsistent states.
+
+ LAC is a new mechanism within the parsing algorithm that solves
+ these problems for canonical LR, IELR, and LALR without sacrificing
+ %nonassoc, default reductions, or state merging. When LAC is in
+ use, canonical LR and IELR behave almost exactly the same for both
+ syntactically acceptable and syntactically unacceptable input.
+ While LALR still does not support the full language-recognition
+ power of canonical LR and IELR, LAC at least enables LALR's syntax
+ error handling to correctly reflect LALR's language-recognition
+ power.
+
+ Currently, LAC is only supported for deterministic parsers in C.
+ You can enable LAC with the following directive:
+
+ %define parse.lac full
+
+ See the new section `LAC' in the Bison manual for additional
+ details including a few caveats.
+
+ LAC is an experimental feature. More user feedback will help to
+ stabilize it.
+
+** %define improvements:
+
+*** Can now be invoked via the command line:
+
+ Each of these command-line options
+
+ -D NAME[=VALUE]
+ --define=NAME[=VALUE]
+
+ -F NAME[=VALUE]
+ --force-define=NAME[=VALUE]
+
+ is equivalent to this grammar file declaration
+
+ %define NAME ["VALUE"]
+
+ except that the manner in which Bison processes multiple definitions
+ for the same NAME differs. Most importantly, -F and --force-define
+ quietly override %define, but -D and --define do not. For further
+ details, see the section `Bison Options' in the Bison manual.
+
+*** Variables renamed:
+
+ The following %define variables
+
+ api.push_pull
+ lr.keep_unreachable_states
+
+ have been renamed to
+
+ api.push-pull
+ lr.keep-unreachable-states
+
+ The old names are now deprecated but will be maintained indefinitely
+ for backward compatibility.
+
+*** Values no longer need to be quoted in the grammar file:
+
+ If a %define value is an identifier, it no longer needs to be placed
+ within quotations marks. For example,
+
+ %define api.push-pull "push"
+
+ can be rewritten as
+
+ %define api.push-pull push
+
+*** Unrecognized variables are now errors not warnings.
+
+*** Multiple invocations for any variable is now an error not a warning.
+
+** Unrecognized %code qualifiers are now errors not warnings.
+
+** Character literals not of length one:
+
+ Previously, Bison quietly converted all character literals to length
+ one. For example, without warning, Bison interpreted the operators in
+ the following grammar to be the same token:
+
+ exp: exp '++'
+ | exp '+' exp
+ ;
+
+ Bison now warns when a character literal is not of length one. In
+ some future release, Bison will start reporting an error instead.
+
+** Destructor calls fixed for lookaheads altered in semantic actions:
+
+ Previously for deterministic parsers in C, if a user semantic action
+ altered yychar, the parser in some cases used the old yychar value to
+ determine which destructor to call for the lookahead upon a syntax
+ error or upon parser return. This bug has been fixed.
+
+** C++ parsers use YYRHSLOC:
+
+ Similarly to the C parsers, the C++ parsers now define the YYRHSLOC
+ macro and use it in the default YYLLOC_DEFAULT. You are encouraged
+ to use it. If, for instance, your location structure has `first'
+ and `last' members, instead of
+
+ # define YYLLOC_DEFAULT(Current, Rhs, N) \
+ do \
+ if (N) \
+ { \
+ (Current).first = (Rhs)[1].location.first; \
+ (Current).last = (Rhs)[N].location.last; \
+ } \
+ else \
+ { \
+ (Current).first = (Current).last = (Rhs)[0].location.last; \
+ } \
+ while (false)
+
+ use:
+
+ # define YYLLOC_DEFAULT(Current, Rhs, N) \
+ do \
+ if (N) \
+ { \
+ (Current).first = YYRHSLOC (Rhs, 1).first; \
+ (Current).last = YYRHSLOC (Rhs, N).last; \
+ } \
+ else \
+ { \
+ (Current).first = (Current).last = YYRHSLOC (Rhs, 0).last; \
+ } \
+ while (false)
+
+** YYLLOC_DEFAULT in C++:
+
+ The default implementation of YYLLOC_DEFAULT used to be issued in
+ the header file. It is now output in the implementation file, after
+ the user %code sections so that its #ifndef guard does not try to
+ override the user's YYLLOC_DEFAULT if provided.
+
+** YYFAIL now produces warnings and Java parsers no longer implement it:
+
+ YYFAIL has existed for many years as an undocumented feature of
+ deterministic parsers in C generated by Bison. More recently, it was
+ a documented feature of Bison's experimental Java parsers. As
+ promised in Bison 2.4.2's NEWS entry, any appearance of YYFAIL in a
+ semantic action now produces a deprecation warning, and Java parsers
+ no longer implement YYFAIL at all. For further details, including a
+ discussion of how to suppress C preprocessor warnings about YYFAIL
+ being unused, see the Bison 2.4.2 NEWS entry.
+
+** Temporary hack for adding a semicolon to the user action:
+
+ Previously, Bison appended a semicolon to every user action for
+ reductions when the output language defaulted to C (specifically, when
+ neither %yacc, %language, %skeleton, or equivalent command-line
+ options were specified). This allowed actions such as
+
+ exp: exp "+" exp { $$ = $1 + $3 };
+
+ instead of
+
+ exp: exp "+" exp { $$ = $1 + $3; };
+
+ As a first step in removing this misfeature, Bison now issues a
+ warning when it appends a semicolon. Moreover, in cases where Bison
+ cannot easily determine whether a semicolon is needed (for example, an
+ action ending with a cpp directive or a braced compound initializer),
+ it no longer appends one. Thus, the C compiler might now complain
+ about a missing semicolon where it did not before. Future releases of
+ Bison will cease to append semicolons entirely.
+
+** Verbose syntax error message fixes:
+
+ When %error-verbose or the obsolete `#define YYERROR_VERBOSE' is
+ specified, syntax error messages produced by the generated parser
+ include the unexpected token as well as a list of expected tokens.
+ The effect of %nonassoc on these verbose messages has been corrected
+ in two ways, but a more complete fix requires LAC, described above:
+
+*** When %nonassoc is used, there can exist parser states that accept no
+ tokens, and so the parser does not always require a lookahead token
+ in order to detect a syntax error. Because no unexpected token or
+ expected tokens can then be reported, the verbose syntax error
+ message described above is suppressed, and the parser instead
+ reports the simpler message, `syntax error'. Previously, this
+ suppression was sometimes erroneously triggered by %nonassoc when a
+ lookahead was actually required. Now verbose messages are
+ suppressed only when all previous lookaheads have already been
+ shifted or discarded.
+
+*** Previously, the list of expected tokens erroneously included tokens
+ that would actually induce a syntax error because conflicts for them
+ were resolved with %nonassoc in the current parser state. Such
+ tokens are now properly omitted from the list.
+
+*** Expected token lists are still often wrong due to state merging
+ (from LALR or IELR) and default reductions, which can both add
+ invalid tokens and subtract valid tokens. Canonical LR almost
+ completely fixes this problem by eliminating state merging and
+ default reductions. However, there is one minor problem left even
+ when using canonical LR and even after the fixes above. That is,
+ if the resolution of a conflict with %nonassoc appears in a later
+ parser state than the one at which some syntax error is
+ discovered, the conflicted token is still erroneously included in
+ the expected token list. Bison's new LAC implementation,
+ described above, eliminates this problem and the need for
+ canonical LR. However, LAC is still experimental and is disabled
+ by default.
+
+** Java skeleton fixes:
+
+*** A location handling bug has been fixed.
+
+*** The top element of each of the value stack and location stack is now
+ cleared when popped so that it can be garbage collected.
+
+*** Parser traces now print the top element of the stack.
+
+** -W/--warnings fixes:
+
+*** Bison now properly recognizes the `no-' versions of categories:
+
+ For example, given the following command line, Bison now enables all
+ warnings except warnings for incompatibilities with POSIX Yacc:
+
+ bison -Wall,no-yacc gram.y
+
+*** Bison now treats S/R and R/R conflicts like other warnings:
+
+ Previously, conflict reports were independent of Bison's normal
+ warning system. Now, Bison recognizes the warning categories
+ `conflicts-sr' and `conflicts-rr'. This change has important
+ consequences for the -W and --warnings command-line options. For
+ example:
+
+ bison -Wno-conflicts-sr gram.y # S/R conflicts not reported
+ bison -Wno-conflicts-rr gram.y # R/R conflicts not reported
+ bison -Wnone gram.y # no conflicts are reported
+ bison -Werror gram.y # any conflict is an error
+
+ However, as before, if the %expect or %expect-rr directive is
+ specified, an unexpected number of conflicts is an error, and an
+ expected number of conflicts is not reported, so -W and --warning
+ then have no effect on the conflict report.
+
+*** The `none' category no longer disables a preceding `error':
+
+ For example, for the following command line, Bison now reports
+ errors instead of warnings for incompatibilities with POSIX Yacc:
+
+ bison -Werror,none,yacc gram.y
+
+*** The `none' category now disables all Bison warnings:
+
+ Previously, the `none' category disabled only Bison warnings for
+ which there existed a specific -W/--warning category. However,
+ given the following command line, Bison is now guaranteed to
+ suppress all warnings:
+
+ bison -Wnone gram.y
+
+** Precedence directives can now assign token number 0:
+
+ Since Bison 2.3b, which restored the ability of precedence
+ directives to assign token numbers, doing so for token number 0 has
+ produced an assertion failure. For example:
+
+ %left END 0
projects / bison.git / blobdiff