X-Git-Url: https://git.saurik.com/bison.git/blobdiff_plain/9b8a5ce03b0b8c119913a83e65b638a25f854ceb..d508c2816f6f0a3f44a1ff5d6526585c10826950:/doc/bison.texinfo

diff --git a/doc/bison.texinfo b/doc/bison.texinfo
index f4a0cbec..641e6db5 100644
--- a/doc/bison.texinfo
+++ b/doc/bison.texinfo
@@ -3800,7 +3800,7 @@ For instance, if your locations use a file name, you may use
 %parse-param @{ char const *file_name @};
 %initial-action
 @{
-  @@$.begin.filename = @@$.end.filename = file_name;
+  @@$.initialize (file_name);
 @};
 @end example
 
@@ -3810,28 +3810,28 @@ For instance, if your locations use a file name, you may use
 @cindex freeing discarded symbols
 @findex %destructor
 
-Some symbols can be discarded by the parser.  During error
-recovery (@pxref{Error Recovery}), symbols already pushed
-on the stack and tokens coming from the rest of the file
-are discarded until the parser falls on its feet.  If the parser
-runs out of memory, all the symbols on the stack must be discarded.
-Even if the parser succeeds, it must discard the start symbol.
+Some symbols can be discarded by the parser.  During error recovery
+(@pxref{Error Recovery}), symbols already pushed on the stack and tokens
+coming from the rest of the file are discarded until the parser falls on
+its feet.  If the parser runs out of memory, all the symbols on the
+stack must be discarded.  Even if the parser succeeds, it must discard
+the start symbol.
 
 When discarded symbols convey heap based information, this memory is
 lost.  While this behavior can be tolerable for batch parsers, such as
-in traditional compilers, it is unacceptable for programs like shells
-or protocol implementations that may parse and execute indefinitely.
+in traditional compilers, it is unacceptable for programs like shells or
+protocol implementations that may parse and execute indefinitely.
 
 The @code{%destructor} directive defines code that
 is called when a symbol is discarded.
 
 @deffn {Directive} %destructor @{ @var{code} @} @var{symbols}
 @findex %destructor
-Invoke @var{code} whenever the parser discards one of the
-@var{symbols}.  Within @var{code}, @code{$$} designates the semantic
-value associated with the discarded symbol.  The additional
-parser parameters are also available
-(@pxref{Parser Function, , The Parser Function @code{yyparse}}).
+Invoke @var{code} whenever the parser discards one of the @var{symbols}.
+Within @var{code}, @code{$$} designates the semantic value associated
+with the discarded symbol.  The additional parser parameters are also
+available (@pxref{Parser Function, , The Parser Function
+@code{yyparse}}).
 
 @strong{Warning:} as of Bison 2.1, this feature is still
 experimental, as there has not been enough user feedback.  In particular,
@@ -3913,19 +3913,18 @@ The declaration looks like this:
 %expect @var{n}
 @end example
 
-Here @var{n} is a decimal integer.  The declaration says there should be
-no warning if there are @var{n} shift/reduce conflicts and no
-reduce/reduce conflicts.  The usual warning is
-given if there are either more or fewer conflicts, or if there are any
-reduce/reduce conflicts.
+Here @var{n} is a decimal integer.  The declaration says there should
+be @var{n} shift/reduce conflicts and no reduce/reduce conflicts.
+Bison reports an error if the number of shift/reduce conflicts differs
+from @var{n}, or if there are any reduce/reduce conflicts.
 
-For normal @acronym{LALR}(1) parsers, reduce/reduce conflicts are more serious,
-and should be eliminated entirely.  Bison will always report
-reduce/reduce conflicts for these parsers.  With @acronym{GLR} parsers, however,
-both shift/reduce and reduce/reduce are routine (otherwise, there
-would be no need to use @acronym{GLR} parsing).  Therefore, it is also possible
-to specify an expected number of reduce/reduce conflicts in @acronym{GLR}
-parsers, using the declaration:
+For normal @acronym{LALR}(1) parsers, reduce/reduce conflicts are more
+serious, and should be eliminated entirely.  Bison will always report
+reduce/reduce conflicts for these parsers.  With @acronym{GLR}
+parsers, however, both kinds of conflicts are routine; otherwise,
+there would be no need to use @acronym{GLR} parsing.  Therefore, it is
+also possible to specify an expected number of reduce/reduce conflicts
+in @acronym{GLR} parsers, using the declaration:
 
 @example
 %expect-rr @var{n}
@@ -3946,12 +3945,12 @@ go back to the beginning.
 
 @item
 Add an @code{%expect} declaration, copying the number @var{n} from the
-number which Bison printed.
+number which Bison printed.  With @acronym{GLR} parsers, add an
+@code{%expect-rr} declaration as well.
 @end itemize
 
-Now Bison will stop annoying you if you do not change the number of
-conflicts, but it will warn you again if changes in the grammar result
-in more or fewer conflicts.
+Now Bison will warn you if you introduce an unexpected conflict, but
+will keep silent otherwise.
 
 @node Start Decl
 @subsection The Start-Symbol