by default (@pxref{Location Type, ,Data Types of Locations}), which is a
four member structure with the following integer fields:
@code{first_line}, @code{first_column}, @code{last_line} and
-@code{last_column}.
+@code{last_column}. By conventions, and in accordance with the GNU
+Coding Standards and common practice, the line and column count both
+start at 1.
@node Ltcalc Rules
@subsection Grammar Rules for @code{ltcalc}
@dots{}
@end smallexample
+@findex %before-header
+@findex %start-header
+@findex %after-header
+If you've instructed Bison to generate a header file (@pxref{Table of Symbols,
+,%defines}), you probably want @code{#include "ptypes.h"} to appear
+in that header file as well.
+In that case, use @code{%before-header}, @code{%start-header}, and
+@code{%after-header} instead of @var{Prologue} sections
+(@pxref{Table of Symbols, ,%start-header}):
+
+@smallexample
+%before-header @{
+ #include <stdio.h>
+@}
+
+%start-header @{
+ #include "ptypes.h"
+@}
+%union @{
+ long int n;
+ tree t; /* @r{@code{tree} is defined in @file{ptypes.h}.} */
+@}
+
+%after-header @{
+ static void print_token_value (FILE *, int, YYSTYPE);
+ #define YYPRINT(F, N, L) print_token_value (F, N, L)
+@}
+
+@dots{}
+@end smallexample
+
@node Bison Declarations
@subsection The Bison Declarations Section
@cindex Bison declarations (introduction)
@} YYLTYPE;
@end example
+At the beginning of the parsing, Bison initializes all these fields to 1
+for @code{yylloc}.
+
@node Actions and Locations
@subsection Actions and Locations
@cindex location actions
typically needs to be able to refer to the above-mentioned declarations
and to the token type codes. @xref{Token Values, ,Semantic Values of
Tokens}.
+
+@findex %start-header
+@findex %end-header
+If you have declared @code{%start-header} or @code{%end-header}, the output
+header also contains their code.
+@xref{Table of Symbols, ,%start-header}.
@end deffn
@deffn {Directive} %destructor
other minor ways. Most importantly, imitate Yacc's output
file name conventions, so that the parser output file is called
@file{y.tab.c}, and the other outputs are called @file{y.output} and
-@file{y.tab.h}. Thus, the following shell script can substitute
-for Yacc, and the Bison distribution contains such a script for
-compatibility with @acronym{POSIX}:
+@file{y.tab.h}.
+Also, if generating an @acronym{LALR}(1) parser in C, generate @code{#define}
+statements in addition to an @code{enum} to associate token numbers with token
+names.
+Thus, the following shell script can substitute for Yacc, and the Bison
+distribution contains such a script for compatibility with @acronym{POSIX}:
@example
#! /bin/sh
@end example
@noindent
+@findex %start-header
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
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{Table of Symbols, ,%start-header}.
@comment file: calc++-parser.yy
@example
-%@{
+%start-header @{
# include <string>
class calcxx_driver;
-%@}
+@}
@end example
@noindent
@end example
@noindent
-The code between @samp{%@{} and @samp{%@}} after the introduction of the
-@samp{%union} is output in the @file{*.cc} file; it needs detailed
-knowledge about the driver.
+@findex %after-header
+The code between @samp{%after-header @{} and @samp{@}} is output in the
+@file{*.cc} file; it needs detailed knowledge about the driver.
@comment file: calc++-parser.yy
@example
-%@{
+%after-header @{
# include "calc++-driver.hh"
-%@}
+@}
@end example
Start-Symbol}. It cannot be used in the grammar.
@end deffn
+@deffn {Directive} %after-header @{@var{code}@}
+Specifies code to be inserted into the code file after the contents of the
+header file.
+@xref{Table of Symbols, ,%start-header}.
+@end deffn
+
+@deffn {Directive} %before-header @{@var{code}@}
+Specifies code to be inserted into the code file before the contents of the
+header file.
+@xref{Table of Symbols, ,%start-header}.
+@end deffn
+
+@deffn {Directive} %end-header @{@var{code}@}
+Specifies code to be inserted both into the header file (if generated;
+@pxref{Table of Symbols, ,%defines}) and into the code file after any
+Bison-generated definitions.
+@xref{Table of Symbols, ,%start-header}.
+@end deffn
+
+@deffn {Directive} %start-header @{@var{code}@}
+Specifies code to be inserted both into the header file (if generated;
+@pxref{Table of Symbols, ,%defines}) and into the code file before any
+Bison-generated definitions.
+
+@cindex Prologue
+@findex %before-header
+@findex %union
+@findex %end-header
+@findex %after-header
+For example, the following declaration order in the grammar file reflects the
+order in which Bison will output these code blocks. However, you are free to
+declare these code blocks in your grammar file in whatever order is most
+convenient for you:
+
+@smallexample
+%before-header @{
+ /* Bison treats this block like a pre-prologue block: it inserts it
+ * into the code file before the contents of the header file. It
+ * does *not* insert it into the header file. This is a good place
+ * to put #include's that you want at the top of your code file. A
+ * common example is `#include "system.h"'. */
+@}
+%start-header @{
+ /* Bison inserts this block into both the header file and the code
+ * file. In both files, the point of insertion is before any
+ * Bison-generated token, semantic type, location type, and class
+ * definitions. This is a good place to define %union
+ * dependencies, for example. */
+@}
+%union @{
+ /* Unlike the traditional Yacc prologue blocks, the output order
+ * for the %*-header blocks is not affected by their declaration
+ * position relative to any %union in the grammar file. */
+@}
+%end-header @{
+ /* Bison inserts this block into both the header file and the code
+ * file. In both files, the point of insertion is after the
+ * Bison-generated definitions. This is a good place to declare or
+ * define public functions or data structures that depend on the
+ * Bison-generated definitions. */
+@}
+%after-header @{
+ /* Bison treats this block like a post-prologue block: it inserts
+ * it into the code file after the contents of the header file. It
+ * does *not* insert it into the header file. This is a good place
+ * to declare or define internal functions or data structures that
+ * depend on the Bison-generated definitions. */
+@}
+@end smallexample
+
+If you have multiple occurrences of any one of the above declarations, Bison
+will concatenate the contents in declaration order.
+
+@xref{Prologue, ,The Prologue}.
+@end deffn
+
+@deffn {Directive} %debug
+Equip the parser for debugging. @xref{Decl Summary}.
+@end deffn
+
@deffn {Directive} %debug
Equip the parser for debugging. @xref{Decl Summary}.
@end deffn
projects / bison.git / blobdiff