-Bison News
-----------
+GNU Bison NEWS
-* Changes in version 2.5.1_rc1 (2012-05-14):
+* Noteworthy changes in release ?.? (????-??-??) [?]
+
+** Additional yylex/yyparse arguments
+
+ The new directive %param declare additional argument 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++ skeleton improvements
+
+ 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
+
+ The variable error 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
+ runtime expressions.
+
+* Noteworthy changes in release ?.? (????-??-??) [?]
+
+** Future changes:
+
+ The next major release will drop support for generating parsers in K&R C,
+ and remove the definition of yystype (removal announced since Bison
+ 1.875).
+
+** The generated header is included (yacc.c)
+
+ Instead of duplicating the content of the generated header (definition of
+ YYSTYPE, yyltype etc.), the generated parser now includes it, as was
+ already the case for GLR or C++ parsers.
+
+** Headers (yacc.c, glr.c, glr.cc)
+
+*** Guards
+
+ The generated headers are now guarded, as is already the case for C++
+ parsers (lalr1.cc). For intance, with --defines=foo.h:
+
+ #ifndef YY_FOO_H
+ # define YY_FOO_H
+ ...
+ #endif /* !YY_FOO_H */
+
+*** New declarations
+
+ The generated header now declares yydebug and yyparse. Both honor
+ --name-prefix=bar_, and yield
+
+ int bar_parse (void);
+
+ rather than
+
+ #define yyparse bar_parse
+ int yyparse (void);
+
+ in order to facilitate the inclusion of several parser headers inside a
+ single compilation unit.
+
+* Noteworthy changes in release 2.5.1 (2012-06-05) [stable]
** Future changes:
This includes warnings with some compilers, unexpected behavior of tools
such as diff, warning messages from the test suite itself, etc.
-*** The install-pdf target work properly:
+*** The install-pdf target works properly:
Running "make install-pdf" (or -dvi, -html, -info, and -ps) no longer
halts in the middle of its course.
if the symbols have destructors. For instance:
exp: exp "?" exp ":" exp { $1 ? $1 : $3; }
- | exp "+" exp
- ;
+ | exp "+" exp
+ ;
will trigger a warning about $$ and $5 in the first rule, and $3 in
the second ($1 is copied to $$ by the default rule). This example
most likely contains three errors, and could be rewritten as:
exp: exp "?" exp ":" exp
- { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
- | exp "+" exp
- { $$ = $1 ? $1 : $3; if ($1) free ($3); }
- ;
+ { $$ = $1 ? $3 : $5; free ($1 ? $5 : $3); free ($1); }
+ | exp "+" exp
+ { $$ = $1 ? $1 : $3; if ($1) free ($3); }
+ ;
However, if the original actions were really intended, memory leaks
and all, the warnings can be suppressed by letting Bison believe the
values are used, e.g.:
exp: exp "?" exp ":" exp { $1 ? $1 : $3; (void) ($$, $5); }
- | exp "+" exp { $$ = $1; (void) $3; }
- ;
+ | exp "+" exp { $$ = $1; (void) $3; }
+ ;
If there are mid-rule actions, the warning is issued if no action
uses it. The following triggers no warning: $1 and $3 are used.
In agreement with POSIX and with other Yaccs, leaving a default
action is valid when $$ is untyped, and $1 typed:
- untyped: ... typed;
+ untyped: ... typed;
but the converse remains an error:
- typed: ... untyped;
+ typed: ... untyped;
** Values of mid-rule actions
The following code:
- foo: { ... } { $$ = $1; } ...
+ foo: { ... } { $$ = $1; } ...
was incorrectly rejected: $1 is defined in the second mid-rule
action, and is equal to the $$ of the first mid-rule action.
projects / bison.git / blobdiff