like @samp{%glr-parser}, Bison might not be Yacc-compatible even if
this option is specified.
+@item -W
+@itemx --warnings
+Output warnings falling in @var{category}. @var{category} can be one
+of:
+@table @code
+@item midrule-values
+Warn about mid-rule values that are set but not used within any of the actions
+of the parent rule.
+For example, warn about unused @code{$2} in:
+
+@example
+exp: '1' @{ $$ = 1; @} '+' exp @{ $$ = $1 + $4; @};
+@end example
+
+Also warn about mid-rule values that are used but not set.
+For example, warn about unset @code{$$} in the mid-rule action in:
+
+@example
+ exp: '1' @{ $1 = 1; @} '+' exp @{ $$ = $2 + $4; @};
+@end example
+
+These warnings are not enabled by default since they sometimes prove to
+be false alarms in existing grammars employing the Yacc constructs
+@code{$0} or @code{$-@var{n}} (where @var{n} is some positive integer).
+
+
+@item yacc
+Incompatibilities with @acronym{POSIX} Yacc.
+
+@item all
+All the warnings.
+@item none
+Turn off all the warnings.
+@item error
+Treat warnings as errors.
+@end table
+
+A category can be turned off by prefixing its name with @samp{no-}. For
+instance, @option{-Wno-syntax} will hide the warnings about unused
+variables.
@end table
@noindent
Adjust the output:
@table @option
-@item -d
-@itemx --defines
+@item --defines[=@var{file}]
Pretend that @code{%defines} was specified, i.e., write an extra output
file containing macro definitions for the token type names defined in
the grammar, as well as a few other declarations. @xref{Decl Summary}.
-@item --defines=@var{defines-file}
-Same as above, but save in the file @var{defines-file}.
+@item -d
+This is the same as @code{--defines} except @code{-d} does not accept a
+@var{file} argument since POSIX Yacc requires that @code{-d} can be bundled
+with other short options.
@item -b @var{file-prefix}
@itemx --file-prefix=@var{prefix}
The other output files' names are constructed from @var{file} as
described under the @samp{-v} and @samp{-d} options.
-@item -g
+@item -g[@var{file}]
+@itemx --graph[=@var{file}]
Output a graphical representation of the @acronym{LALR}(1) grammar
automaton computed by Bison, in @uref{http://www.graphviz.org/, Graphviz}
@uref{http://www.graphviz.org/doc/info/lang.html, @acronym{DOT}} format.
-If the grammar file is @file{foo.y}, the output file will
-be @file{foo.dot}.
-
-@item --graph=@var{graph-file}
-The behavior of @var{--graph} is the same as @samp{-g}. The only
-difference is that it has an optional argument which is the name of
-the output graph file.
+@code{@var{file}} is optional.
+If omitted and the grammar file is @file{foo.y}, the output file will be
+@file{foo.dot}.
-@item -x
-@itemx --xml=@var{file}
+@item -x[@var{file}]
+@itemx --xml[=@var{file}]
Output an XML report of the @acronym{LALR}(1) automaton computed by Bison.
-@code{=@var{file}} is optional.
+@code{@var{file}} is optional.
If omitted and the grammar file is @file{foo.y}, the output file will be
@file{foo.xml}.
(The current XML schema is experimental and may evolve.
The parser class defines an inner class, @code{Location}, that is used
for location tracking. If the parser is pure, it also defines an
-inner interface, @code{Lexer}; see~@ref{Java Scanner Interface} for the
+inner interface, @code{Lexer}; see @ref{Java Scanner Interface} for the
meaning of pure parsers when the Java language is chosen. Other than
-these inner class/interface, and the members described in~@ref{Java
+these inner class/interface, and the members described in @ref{Java
Parser Interface}, all the other members and fields are preceded
with a @code{yy} prefix to avoid clashes with user code.
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}
directive does not do anything when used in Java.
+@c FIXME: But a bit farther it is stated that
+@c If @code{%pure-parser} is not specified, the lexer interface
+@c resides in the same class (@code{YYParser}) as the Bison-generated
+@c parser. The fields and methods that are provided to
+@c this end are as follows.
The scanner always resides in a separate class than the parser.
-Still, Java also two possible ways to interface a Bison-generated Java
+Still, there are two possible ways to interface a Bison-generated Java
parser with a scanner, that is, the scanner may reside in a separate file
than the Bison grammar, or in the same file. The interface
to the scanner is similar in the two cases.
specify them with @code{%lex-param}; they are passed before
@code{%parse-param}s to the constructor.
-In the second case, the scanner has to implement interface @code{Lexer},
+In the second case, the scanner has to implement the @code{Lexer} interface,
which is defined within the parser class (e.g., @code{YYParser.Lexer}).
The constructor of the parser object will then accept an object
implementing the interface; @code{%lex-param} is not used in this
@end deftypemethod
@deftypemethod {Lexer} {Object} getLVal ()
-Return respectively the first position of the last token that yylex
-returned, and the first position beyond it.
+Return the semantical value of the last token that yylex returned.
The return type can be changed using @samp{%define "stype"
"@var{class-name}".}
The fields and methods that are provided to this end are as follows.
@deftypemethod {YYParser} {void} error (Location @var{l}, String @var{m})
-As explained in @pxref{Java Parser Interface}, this method is defined
+As already explained (@pxref{Java Parser Interface}), this method is defined
by the user to emit an error message. The first parameter is not used
unless location tracking is active. Its type can be changed using
@samp{%define "location_type" "@var{class-name}".}
projects / bison.git / blobdiff