CHANGES_FROM_1.33
上传用户:itx_2006
上传日期:2007-01-06
资源大小:493k
文件大小:165k
源码类别:

编译器/解释器

开发平台:

Others

  1.            WITH predicate: line 11  v4.g
  2.            WITHOUT predicate: line 12  v4.g
  3.         The original context set for the predicate:
  4.              A                X
  5.         The lookahead set for the alt WITHOUT the semantic predicate:
  6.              A
  7.         The intersection of the two sets
  8.              A
  9.         The original predicate:
  10.           pred <<  isUpper(LATEXT(1))>>?
  11.                           depth=k=1  rule b  line 15  v4.g
  12.             set context:
  13.                A                X
  14.             tree context: null
  15.         The new (modified) form of the predicate:
  16.           pred <<  isUpper(LATEXT(1))>>?
  17.                           depth=k=1  rule b  line 15  v4.g
  18.             set context:
  19.                X
  20.             tree context: null
  21.         #endif
  22.       --------------------------------------------------------------
  23.       The bad news about -mrhoist:
  24.         (a) -mrhoist does not analyze predicates with lookahead
  25.             depth > 1.
  26.         (b) -mrhoist does not look past a guarded predicate to
  27.             find context which might cover other predicates.
  28.       For these cases you might want to use syntactic predicates.
  29.       When a semantic predicate fails during guess mode the guess
  30.       fails and the next alternative is tried.
  31.       Limitation (a) is illustrated by the following example:
  32.         start    : (stmt)* EOF ;
  33.         stmt     : cast
  34.                  | expr
  35.                  ;
  36.         cast     : <<isTypename(LATEXT(2))>>? LP ID RP ;
  37.         expr     : LP ID RP ;
  38.       This is not much different from the first example, except that
  39.       it requires two tokens of lookahead context to determine what
  40.       to do.  This predicate is NOT suppressed because the current version
  41.       is unable to handle predicates with depth > 1.
  42.       A predicate can be combined with other predicates during hoisting.
  43.       In those cases the depth=1 predicates are still handled.  Thus,
  44.       in the following example the isUpper() predicate will be suppressed
  45.       by line #4 when hoisted from "bizarre" into "start", but will still
  46.       be present in "bizarre" in order to predict "stmt".
  47.         start    : (bizarre)* EOF ;     // #1
  48.                                         // #2
  49.         bizarre  : stmt                 // #3
  50.                  | A                    // #4
  51.                  ;
  52.         stmt     : cast
  53.                  | expr
  54.                  ;
  55.         cast     : <<isTypename(LATEXT(2))>>? LP ID RP ;
  56.         expr     : LP ID RP ;
  57.                  | <<isUpper(LATEXT(1))>>? A
  58.       Limitation (b) is illustrated by the following example of a
  59.       context guarded predicate:
  60.         rule : (A)? <<p>>?          // #1
  61.                      (A             // #2
  62.                      |B             // #3
  63.                      )              // #4
  64.              | <<q>> B              // #5
  65.              ;
  66.       Recall that this means that when the lookahead is NOT A then
  67.       the predicate "p" is ignored and it attempts to match "A|B".
  68.       Ideally, the "B" at line #3 should suppress predicate "q".
  69.       However, the current version does not attempt to look past
  70.       the guard predicate to find context which might suppress other
  71.       predicates.
  72.       In some cases -mrhoist will lead to the reporting of ambiguities
  73.       which were not visible before:
  74.         start   : (a)* "@";
  75.         a       : bc | d;
  76.         bc      : b  | c ;
  77.         b       : <<isUpper(LATEXT(1))>>? A;
  78.         c       : A ;
  79.         d       : A ;
  80.       In this case there is a true ambiguity in "a" between "bc" and "d"
  81.       which can both match "A".  Without -mrhoist the predicate in "b"
  82.       is hoisted into "a" and there is no ambiguity reported.  However,
  83.       with -mrhoist, the predicate in "b" is suppressed by "c" (as it
  84.       should be) making the ambiguity in "a" apparent.
  85.       The motivations for these changes were hoisting problems reported
  86.       by Reinier van den Born (reinier@vnet.ibm.com) and several others.
  87. #116. (Changed in 1.33MR10) C++ mode: tracein/traceout rule name is (const char *)
  88.       The prototype for C++ mode routine tracein (and traceout) has changed from
  89.       "char *" to "const char *".
  90. #115. (Changed in 1.33MR10) Using guess mode with exception handlers in C mode
  91.       The definition of the C mode macros zzmatch_wsig and zzsetmatch_wsig
  92.       neglected to consider guess mode.  When control passed to the rule's
  93.       parse exception handler the routine would exit without ever closing the
  94.       guess block. This would lead to unpredictable behavior.
  95.       In 1.33MR10 the behavior of exceptions in C mode and C++ mode should be
  96.       identical.
  97. #114. (Changed in 1.33MR10) difference in [zz]resynch() between C and C++ modes
  98.       There was a slight difference in the way C and C++ mode resynchronized
  99.       following a parsing error.  The C routine would sometimes skip an extra
  100.       token before attempting to resynchronize.
  101.       The C routine was changed to match the C++ routine.
  102. #113. (Changed in 1.33MR10) new context guarded pred: (g)? && <<p>>? expr
  103.       The existing context guarded predicate:
  104.             rule : (guard)? => <<p>>? expr
  105.                  | next_alternative
  106.                  ;
  107.       generates code which resembles:
  108.             if (lookahead(expr) && (!guard || pred)) {
  109.               expr()
  110.             } else ....
  111.       This is not suitable for some applications because it allows
  112.       expr() to be invoked when the predicate is false.  This is
  113.       intentional because it is meant to mimic automatically computed
  114.       predicate context.
  115.       The new context guarded predicate uses the guard information
  116.       differently because it has a different goal.  Consider:
  117.             rule : (guard)? && <<p>>? expr
  118.                  | next_alternative
  119.                  ;
  120.       The new style of context guarded predicate is equivalent to:
  121.             rule : <<guard==true && pred>>? expr
  122.                  | next_alternative
  123.                  ;
  124.       It generates code which resembles:
  125.             if (lookahead(expr) && guard && pred) {
  126.                 expr();
  127.             } else ...
  128.       Both forms of guarded predicates severely restrict the form of
  129.       the context guard: it can contain no rule references, no
  130.       (...)*, no (...)+, and no {...}.  It may contain token and
  131.       token class references, and alternation ("|").
  132.       Addition for 1.33MR11: in the token expression all tokens must
  133.       be at the same height of the token tree:
  134.             (A ( B | C))? && ...            is ok (all height 2)
  135.             (A ( B |  ))? && ...            is not ok (some 1, some 2)
  136.             (A B C D | E F G H)? && ...     is ok (all height 4)
  137.             (A B C D | E )? && ...          is not ok (some 4, some 1)
  138.       This restriction is required in order to properly compute the lookahead
  139.       set for expressions like:
  140.             rule1 : (A B C)? && <<pred>>? rule2 ;
  141.             rule2 : (A|X) (B|Y) (C|Z);
  142.       This addition was suggested by Rienier van den Born (reinier@vnet.ibm.com)
  143. #112. (Changed in 1.33MR10) failed validation predicate in C guess mode
  144.       John Lilley (jlilley@empathy.com) suggested that failed validation
  145.       predicates abort a guess rather than reporting a failed error.
  146.       This was installed in C++ mode (Item #4).  Only now was it noticed
  147.       that the fix was never installed for C mode.
  148. #111. (Changed in 1.33MR10) moved zzTRACEIN to before init action
  149.       When the antlr -gd switch is present antlr generates calls to
  150.       zzTRACEIN at the start of a rule and zzTRACEOUT at the exit
  151.       from a rule.  Prior to 1.33MR10 Tthe call to zzTRACEIN was
  152.       after the init-action, which could cause confusion because the
  153.       init-actions were reported with the name of the enclosing rule,
  154.       rather than the active rule.
  155. #110. (Changed in 1.33MR10) antlr command line copied to generated file
  156.       The antlr command line is now copied to the generated file near
  157.       the start.
  158. #109. (Changed in 1.33MR10) improved trace information
  159.       The quality of the trace information provided by the "-gd"
  160.       switch has been improved significantly.  Here is an example
  161.       of the output from a test program.  It shows the rule name,
  162.       the first token of lookahead, the call depth, and the guess
  163.       status:
  164.         exit rule gusxx {"?"} depth 2
  165.         enter rule gusxx {"?"} depth 2
  166.         enter rule gus1 {"o"} depth 3 guessing
  167.         guess done - returning to rule gus1 {"o"} at depth 3
  168.                     (guess mode continues - an enclosing guess is still active)
  169.         guess done - returning to rule gus1 {"Z"} at depth 3
  170.                     (guess mode continues - an enclosing guess is still active)
  171.         exit rule gus1 {"Z"} depth 3 guessing
  172.         guess done - returning to rule gusxx {"o"} at depth 2 (guess mode ends)
  173.         enter rule gus1 {"o"} depth 3
  174.         guess done - returning to rule gus1 {"o"} at depth 3 (guess mode ends)
  175.         guess done - returning to rule gus1 {"Z"} at depth 3 (guess mode ends)
  176.         exit rule gus1 {"Z"} depth 3
  177.         line 1: syntax error at "Z" missing SC
  178.             ...
  179.       Rule trace reporting is controlled by the value of the integer
  180.       [zz]traceOptionValue:  when it is positive tracing is enabled,
  181.       otherwise it is disabled.  Tracing during guess mode is controlled
  182.       by the value of the integer [zz]traceGuessOptionValue.  When
  183.       it is positive AND [zz]traceOptionValue is positive rule trace
  184.       is reported in guess mode.
  185.       The values of [zz]traceOptionValue and [zz]traceGuessOptionValue
  186.       can be adjusted by subroutine calls listed below.
  187.       Depending on the presence or absence of the antlr -gd switch
  188.       the variable [zz]traceOptionValueDefault is set to 0 or 1.  When
  189.       the parser is initialized or [zz]traceReset() is called the
  190.       value of [zz]traceOptionValueDefault is copied to [zz]traceOptionValue.
  191.       The value of [zz]traceGuessOptionValue is always initialzed to 1,
  192.       but, as noted earlier, nothing will be reported unless
  193.       [zz]traceOptionValue is also positive.
  194.       When the parser state is saved/restored the value of the trace
  195.       variables are also saved/restored.  If a restore causes a change in
  196.       reporting behavior from on to off or vice versa this will be reported.
  197.       When the -gd option is selected, the macro "#define zzTRACE_RULES"
  198.       is added to appropriate output files.
  199.         C++ mode
  200.         --------
  201.         int     traceOption(int delta)
  202.         int     traceGuessOption(int delta)
  203.         void    traceReset()
  204.         int     traceOptionValueDefault
  205.         C mode
  206.         --------
  207.         int     zzTraceOption(int delta)
  208.         int     zzTraceGuessOption(int delta)
  209.         void    zzTraceReset()
  210.         int     zzTraceOptionValueDefault
  211.       The argument "delta" is added to the traceOptionValue.  To
  212.       turn on trace when inside a particular rule one:
  213.         rule : <<traceOption(+1);>>
  214.                (
  215.                 rest-of-rule
  216.                )
  217.                <<traceOption(-1);>>
  218.        ;  /* fail clause */ <<traceOption(-1);>>
  219.       One can use the same idea to turn *off* tracing within a
  220.       rule by using a delta of (-1).
  221.       An improvement in the rule trace was suggested by Sramji
  222.       Ramanathan (ps@kumaran.com).
  223. #108. A Note on Deallocation of Variables Allocated in Guess Mode
  224.                             NOTE
  225.         ------------------------------------------------------
  226.         This mechanism only works for heap allocated variables
  227.         ------------------------------------------------------
  228.       The rewrite of the trace provides the machinery necessary
  229.       to properly free variables or undo actions following a
  230.       failed guess.
  231.       The macro zzUSER_GUESS_HOOK(guessSeq,zzrv) is expanded
  232.       as part of the zzGUESS macro.  When a guess is opened
  233.       the value of zzrv is 0.  When a longjmp() is executed to
  234.       undo the guess, the value of zzrv will be 1.
  235.       The macro zzUSER_GUESS_DONE_HOOK(guessSeq) is expanded
  236.       as part of the zzGUESS_DONE macro.  This is executed
  237.       whether the guess succeeds or fails as part of closing
  238.       the guess.
  239.       The guessSeq is a sequence number which is assigned to each
  240.       guess and is incremented by 1 for each guess which becomes
  241.       active.  It is needed by the user to associate the start of
  242.       a guess with the failure and/or completion (closing) of a
  243.       guess.
  244.       Guesses are nested.  They must be closed in the reverse
  245.       of the order that they are opened.
  246.       In order to free memory used by a variable during a guess
  247.       a user must write a routine which can be called to
  248.       register the variable along with the current guess sequence
  249.       number provided by the zzUSER_GUESS_HOOK macro. If the guess
  250.       fails, all variables tagged with the corresponding guess
  251.       sequence number should be released.  This is ugly, but
  252.       it would require a major rewrite of antlr 1.33 to use
  253.       some mechanism other than setjmp()/longjmp().
  254.       The order of calls for a *successful* guess would be:
  255.         zzUSER_GUESS_HOOK(guessSeq,0);
  256.         zzUSER_GUESS_DONE_HOOK(guessSeq);
  257.       The order of calls for a *failed* guess would be:
  258.         zzUSER_GUESS_HOOK(guessSeq,0);
  259.         zzUSER_GUESS_HOOK(guessSeq,1);
  260.         zzUSER_GUESS_DONE_HOOK(guessSeq);
  261.       The default definitions of these macros are empty strings.
  262.       Here is an example in C++ mode.  The zzUSER_GUESS_HOOK and
  263.       zzUSER_GUESS_DONE_HOOK macros and myGuessHook() routine
  264.       can be used without change in both C and C++ versions.
  265.       ----------------------------------------------------------------------
  266.         <<
  267.         #include "AToken.h"
  268.         typedef ANTLRCommonToken ANTLRToken;
  269.         #include "DLGLexer.h"
  270.         int main() {
  271.           {
  272.             DLGFileInput     in(stdin);
  273.             DLGLexer         lexer(&in,2000);
  274.             ANTLRTokenBuffer pipe(&lexer,1);
  275.             ANTLRCommonToken aToken;
  276.             P                parser(&pipe);
  277.             lexer.setToken(&aToken);
  278.             parser.init();
  279.             parser.start();
  280.           };
  281.           fclose(stdin);
  282.           fclose(stdout);
  283.           return 0;
  284.         }
  285.         >>
  286.         <<
  287.         char *s=NULL;
  288.         #undef zzUSER_GUESS_HOOK
  289.         #define zzUSER_GUESS_HOOK(guessSeq,zzrv) myGuessHook(guessSeq,zzrv);
  290.         #undef zzUSER_GUESS_DONE_HOOK
  291.         #define zzUSER_GUESS_DONE_HOOK(guessSeq)   myGuessHook(guessSeq,2);
  292.         void myGuessHook(int guessSeq,int zzrv) {
  293.           if (zzrv == 0) {
  294.             fprintf(stderr,"User hook: starting guess #%dn",guessSeq);
  295.           } else if (zzrv == 1) {
  296.             free (s);
  297.             s=NULL;
  298.             fprintf(stderr,"User hook: failed guess #%dn",guessSeq);
  299.           } else if (zzrv == 2) {
  300.             free (s);
  301.             s=NULL;
  302.             fprintf(stderr,"User hook: ending guess #%dn",guessSeq);
  303.           };
  304.         }
  305.         >>
  306.         #token A    "a"
  307.         #token      "[t  n]"     <<skip();>>
  308.         class P {
  309.         start : (top)+
  310.               ;
  311.         top   : (which) ?   <<fprintf(stderr,"%s is a whichn",s); free(s); s=NULL; >>
  312.               | other       <<fprintf(stderr,"%s is an othern",s); free(s); s=NULL; >>
  313.               ; <<if (s != NULL) free(s); s=NULL; >>
  314.         which : which2
  315.               ;
  316.         which2 : which3
  317.               ;
  318.         which3
  319.               : (label)?         <<fprintf(stderr,"%s is a labeln",s);>>
  320.               | (global)?        <<fprintf(stderr,"%s is a globaln",s);>>
  321.               | (exclamation)?   <<fprintf(stderr,"%s is an exclamationn",s);>>
  322.               ;
  323.         label :       <<s=strdup(LT(1)->getText());>> A ":" ;
  324.         global :      <<s=strdup(LT(1)->getText());>> A "::" ;
  325.         exclamation : <<s=strdup(LT(1)->getText());>> A "!" ;
  326.         other :       <<s=strdup(LT(1)->getText());>> "other" ;
  327.         }
  328.       ----------------------------------------------------------------------
  329.       This is a silly example, but illustrates the idea.  For the input
  330.       "a ::" with tracing enabled the output begins:
  331.       ----------------------------------------------------------------------
  332.         enter rule "start" depth 1
  333.         enter rule "top" depth 2
  334.         User hook: starting guess #1
  335.         enter rule "which" depth 3 guessing
  336.         enter rule "which2" depth 4 guessing
  337.         enter rule "which3" depth 5 guessing
  338.         User hook: starting guess #2
  339.         enter rule "label" depth 6 guessing
  340.         guess failed
  341.         User hook: failed guess #2
  342.         guess done - returning to rule "which3" at depth 5 (guess mode continues
  343.                                                  - an enclosing guess is still active)
  344.         User hook: ending guess #2
  345.         User hook: starting guess #3
  346.         enter rule "global" depth 6 guessing
  347.         exit rule "global" depth 6 guessing
  348.         guess done - returning to rule "which3" at depth 5 (guess mode continues
  349.                                                  - an enclosing guess is still active)
  350.         User hook: ending guess #3
  351.         enter rule "global" depth 6 guessing
  352.         exit rule "global" depth 6 guessing
  353.         exit rule "which3" depth 5 guessing
  354.         exit rule "which2" depth 4 guessing
  355.         exit rule "which" depth 3 guessing
  356.         guess done - returning to rule "top" at depth 2 (guess mode ends)
  357.         User hook: ending guess #1
  358.         enter rule "which" depth 3
  359.         .....
  360.       ----------------------------------------------------------------------
  361.       Remember:
  362.         (a) Only init-actions are executed during guess mode.
  363.         (b) A rule can be invoked multiple times during guess mode.
  364.         (c) If the guess succeeds the rule will be called once more
  365.               without guess mode so that normal actions will be executed.
  366.             This means that the init-action might need to distinguish
  367.               between guess mode and non-guess mode using the variable
  368.               [zz]guessing.
  369. #107. (Changed in 1.33MR10) construction of ASTs in guess mode
  370.       Prior to 1.33MR10, when using automatic AST construction in C++
  371.       mode for a rule, an AST would be constructed for elements of the
  372.       rule even while in guess mode.  In MR10 this no longer occurs.
  373. #106. (Changed in 1.33MR10) guess variable confusion
  374.       In C++ mode a guess which failed always restored the parser state
  375.       using zzGUESS_DONE as part of zzGUESS_FAIL. Prior to 1.33MR10,
  376.       C mode required an explicit call to zzGUESS_DONE after the
  377.       call to zzGUESS_FAIL.
  378.       Consider:
  379.         rule : (alpha)? beta
  380.              | ...
  381.              ;
  382.       The generated code resembles:
  383.             zzGUESS
  384.             if (!zzrv && LA(1)==ID) {   <==== line #1
  385.                 alpha
  386.                 zzGUESS_DONE
  387.                 beta
  388.             } else {
  389.               if (! zzrv) zzGUESS_DONE  <==== line #2a
  390.               ....
  391.       However, in some cases line #2 was rendered:
  392.               if (guessing) zzGUESS_DONE  <==== line #2b
  393.       This would work for simple test cases, but would fail in
  394.       some cases where there was a guess while another guess was active.
  395.       One kind of failure would be to match up the zzGUESS_DONE at line
  396.       #2b with the "outer" guess which was still active.  The outer
  397.       guess would "succeed" when only the inner guess should have
  398.       succeeded.
  399.       In 1.33MR10 the behavior of zzGUESS and zzGUESS_FAIL in C and
  400.       and C++ mode should be identical.
  401.       The same problem appears in 1.33 vanilla in some places.  For
  402.       example:
  403.             start : { (sub)? } ;
  404.       or:
  405.             start : (
  406.                        B
  407.                     |  ( sub )?
  408.                     |  C
  409.                     )+
  410.                     ;
  411.       generates incorrect code.
  412.       The general principle is:
  413.         (a) use [zz]guessing only when deciding between a call to zzFAIL
  414.               or zzGUESS_FAIL
  415.         (b) use zzrv in all other cases
  416.       This problem was discovered while testing changes to item #105.
  417.       I believe this is now fixed.  My apologies.
  418. #105. (Changed in 1.33MR10) guess block as single alt of (...)+
  419.       Prior to 1.33MR10 the following constructs:
  420.         rule_plus : (
  421.                        (sub)?
  422.                     )+
  423.                     ;
  424.         rule_star : (
  425.                       (sub)?
  426.                     )*
  427.                     ;
  428.       generated incorrect code for the guess block (which could result
  429.       in runtime errors) because of an incorrect optimization of a
  430.       block with only a single alternative.
  431.       The fix caused some changes to the fix described in Item #49
  432.       because there are now three code generation sequences for (...)+
  433.       blocks containing a guess block:
  434.         a. single alternative which is a guess block
  435.         b. multiple alternatives in which the last is a guess block
  436.         c. all other cases
  437.       Forms like "rule_star" can have unexpected behavior when there
  438.       is a syntax error: if the subrule "sub" is not matched *exactly*
  439.       then "rule_star" will consume no tokens.
  440.       Reported by Esa Pulkkinen (esap@cs.tut.fi).
  441. #104. (Changed in 1.33MR10) -o option for dlg
  442.       There was problem with the code added by item #74 to handle the
  443.       -o option of dlg.  This should fix it.
  444. #103. (Changed in 1.33MR10) ANDed semantic predicates
  445.       Rescinded.
  446.       The optimization was a mistake.
  447.       The resulting problem is described in Item #150.
  448. #102. (Changed in 1.33MR10) allow "class parser : .... {"
  449.       The syntax of the class statement ("class parser-name {")
  450.       has been extended to allow for the specification of base
  451.       classes.  An arbirtrary number of tokens may now appear
  452.       between the class name and the "{".  They are output
  453.       again when the class declaration is generated.  For
  454.       example:
  455.         class Parser : public MyBaseClassANTLRparser {
  456.       This was suggested by a user, but I don't have a record
  457.       of who it was.
  458. #101. (Changed in 1.33MR10) antlr -info command line switch
  459.         -info
  460.             p   - extra predicate information in generated file
  461.             t   - information about tnode use:
  462.                     at the end of each rule in generated file
  463.                     summary on stderr at end of program
  464.             m   - monitor progress
  465.                     prints name of each rule as it is started
  466.                     flushes output at start of each rule
  467.             f   - first/follow set information to stdout
  468.             0   - no operation (added in 1.33MR11)
  469.       The options may be combined and may appear in any order.
  470.       For example:
  471.         antlr -info ptm -CC -gt -mrhoist on mygrammar.g
  472. #100a. (Changed in 1.33MR10) Predicate tree simplification
  473.       When the same predicates can be referenced in more than one
  474.       alternative of a block large predicate trees can be formed.
  475.       The difference that these optimizations make is so dramatic
  476.       that I have decided to use it even when -mrhoist is not selected.
  477.       Consider the following grammar:
  478.         start : ( all )* ;
  479.         all   : a
  480.               | d
  481.               | e
  482.               | f
  483.               ;
  484.         a     : c A B
  485.               | c A C
  486.               ;
  487.         c     : <<AAA(LATEXT(2))>>?
  488.               ;
  489.         d     : <<BBB(LATEXT(2))>>? B C
  490.               ;
  491.         e     : <<CCC(LATEXT(2))>>? B C
  492.               ;
  493.         f     : e X Y
  494.               ;
  495.       In rule "a" there is a reference to rule "c" in both alternatives.
  496.       The length of the predicate AAA is k=2 and it can be followed in
  497.       alternative 1 only by (A B) while in alternative 2 it can be
  498.       followed only by (A C).  Thus they do not have identical context.
  499.       In rule "all" the alternatives which refer to rules "e" and "f" allow
  500.       elimination of the duplicate reference to predicate CCC.
  501.       The table below summarized the kind of simplification performed by
  502.       1.33MR10.  In the table, X and Y stand for single predicates
  503.       (not trees).
  504.         (OR X (OR Y (OR Z)))  => (OR X Y Z)
  505.         (AND X (AND Y (AND Z)))  => (AND X Y Z)
  506.         (OR X  (... (OR  X Y) ... ))     => (OR X (... Y ... ))
  507.         (AND X (... (AND X Y) ... ))     => (AND X (... Y ... ))
  508.         (OR X  (... (AND X Y) ... ))     => (OR X (...  ... ))
  509.         (AND X (... (OR  X Y) ... ))     => (AND X (...  ... ))
  510.         (AND X)               => X
  511.         (OR X)                => X
  512.       In a test with a complex grammar for a real application, a predicate
  513.       tree with six OR nodes and 12 leaves was reduced to "(OR X Y Z)".
  514.       In 1.33MR10 there is a greater effort to release memory used
  515.       by predicates once they are no longer in use.
  516. #100b. (Changed in 1.33MR1) Suppression of extra predicate tests
  517.       The following optimizations require that -mrhoist be selected.
  518.       It is relatively easy to optimize the code generated for predicate
  519.       gates when they are of the form:
  520.             (AND X Y Z ...)
  521.         or  (OR  X Y Z ...)
  522.       where X, Y, Z, and "..." represent individual predicates (leaves) not
  523.       predicate trees.
  524.       If the predicate is an AND the contexts of the X, Y, Z, etc. are
  525.       ANDed together to create a single Tree context for the group and
  526.       context tests for the individual predicates are suppressed:
  527.       Optimization 1:  (AND X Y Z ...)
  528.         Suppose the context for Xtest is LA(1)==LP and the context for
  529.         Ytest is LA(1)==LP && LA(2)==ID.
  530.             Without the optimization the code would resemble:
  531.                 if (lookaheadContext &&
  532.                     !(LA(1)==LP && LA(1)==LP && LA(2)==ID) ||
  533.                         ( (! LA(1)==LP || Xtest) &&
  534.                           (! (LA(1)==LP || LA(2)==ID) || Xtest)
  535.                         )) {...
  536.             With the -mrhoist optimization the code would resemble:
  537.                 if (lookaheadContext &&
  538.                     ! (LA(1)==LP && LA(2)==ID) || (Xtest && Ytest) {...
  539.       Optimization 2: (OR X Y Z ...) with identical contexts
  540.         Suppose the context for Xtest is LA(1)==ID and for Ytest
  541.         the context is also LA(1)==ID.
  542.             Without the optimization the code would resemble:
  543.                 if (lookaheadContext &&
  544.                     ! (LA(1)==ID || LA(1)==ID) ||
  545.                         (LA(1)==ID && Xtest) ||
  546.                         (LA(1)==ID && Ytest) {...
  547.             With the -mrhoist optimization the code would resemble:
  548.                 if (lookaheadContext &&
  549.                     (! LA(1)==ID) || (Xtest || Ytest) {...
  550.       Optimization 3: (OR X Y Z ...) with distinct contexts
  551.         Suppose the context for Xtest is LA(1)==ID and for Ytest
  552.         the context is also LA(1)==LP.
  553.             Without the optimization the code would resemble:
  554.                 if (lookaheadContext &&
  555.                     ! (LA(1)==ID || LA(1)==LP) ||
  556.                         (LA(1)==ID && Xtest) ||
  557.                         (LA(1)==LP && Ytest) {...
  558.             With the -mrhoist optimization the code would resemble:
  559.                 if (lookaheadContext &&
  560.                         (zzpf=0,
  561.                             (LA(1)==ID && (zzpf=1) && Xtest) ||
  562.                             (LA(1)==LP && (zzpf=1) && Ytest) ||
  563.                             !zzpf) {
  564.             These may appear to be of similar complexity at first,
  565.             but the non-optimized version contains two tests of each
  566.             context while the optimized version contains only one
  567.             such test, as well as eliminating some of the inverted
  568.             logic (" !(...) || ").
  569.       Optimization 4: Computation of predicate gate trees
  570.         When generating code for the gates of predicate expressions
  571.         antlr 1.33 vanilla uses a recursive procedure to generate
  572.         "&&" and "||" expressions for testing the lookahead. As each
  573.         layer of the predicate tree is exposed a new set of "&&" and
  574.         "||" expressions on the lookahead are generated.  In many
  575.         cases the lookahead being tested has already been tested.
  576.         With -mrhoist a lookahead tree is computed for the entire
  577.         lookahead expression.  This means that predicates with identical
  578.         context or context which is a subset of another predicate's
  579.         context disappear.
  580.         This is especially important for predicates formed by rules
  581.         like the following:
  582.             uppperCaseVowel : <<isUpperCase(LATEXT(1))>>?  vowel;
  583.             vowel:          : <<isVowel(LATEXT(1))>>? LETTERS;
  584.         These predicates are combined using AND since both must be
  585.         satisfied for rule upperCaseVowel.  They have identical
  586.         context which makes this optimization very effective.
  587.       The affect of Items #100a and #100b together can be dramatic.  In
  588.       a very large (but real world) grammar one particular predicate
  589.       expression was reduced from an (unreadable) 50 predicate leaves,
  590.       195 LA(1) terms, and 5500 characters to an (easily comprehensible)
  591.       3 predicate leaves (all different) and a *single* LA(1) term.
  592. #99.  (Changed in 1.33MR10) Code generation for expression trees
  593.       Expression trees are used for k>1 grammars and predicates with
  594.       lookahead depth >1.  This optimization must be enabled using
  595.       "-mrhost on".  (Clarification added for 1.33MR11).
  596.       In the processing of expression trees, antlr can generate long chains
  597.       of token comparisons.  Prior to 1.33MR10 there were many redundant
  598.       parenthesis which caused problems for compilers which could handle
  599.       expressions of only limited complexity.  For example, to test an
  600.       expression tree (root R A B C D), antlr would generate something
  601.       resembling:
  602.         (LA(1)==R && (LA(2)==A || (LA(2)==B || (LA(2)==C || LA(2)==D)))))
  603.       If there were twenty tokens to test then there would be twenty
  604.       parenthesis at the end of the expression.
  605.       In 1.33MR10 the generated code for tree expressions resembles:
  606.         (LA(1)==R && (LA(2)==A || LA(2)==B || LA(2)==C || LA(2)==D))
  607.       For "complex" expressions the output is indented to reflect the LA
  608.       number being tested:
  609.         (LA(1)==R
  610.             && (LA(2)==A || LA(2)==B || LA(2)==C || LA(2)==D
  611.                || LA(2)==E || LA(2)==F)
  612.         || LA(1)==S
  613.             && (LA(2)==G || LA(2)==H))
  614.       Suggested by S. Bochnak (S.Bochnak@@microTool.com.pl),
  615. #98.  (Changed in 1.33MR10) Option "-info p"
  616.       When the user selects option "-info p" the program will generate
  617.       detailed information about predicates.  If the user selects
  618.       "-mrhoist on" additional detail will be provided explaining
  619.       the promotion and suppression of predicates.  The output is part
  620.       of the generated file and sandwiched between #if 0/#endif statements.
  621.       Consider the following k=1 grammar:
  622.         start : ( all ) * ;
  623.         all   : ( a
  624.                 | b
  625.                 )
  626.                 ;
  627.         a     : c B
  628.               ;
  629.         c     : <<LATEXT(1)>>?
  630.               | B
  631.               ;
  632.         b     : <<LATEXT(1)>>? X
  633.               ;
  634.       Below is an excerpt of the output for rule "start" for the three
  635.       predicate options (off, on, and maintenance release style hoisting).
  636.       For those who do not wish to use the "-mrhost on" option for code
  637.       generation the option can be used in a "diagnostic" mode to provide
  638.       valuable information:
  639.             a. where one should insert null actions to inhibit hoisting
  640.             b. a chain of rule references which shows where predicates are
  641.                being hoisted
  642.       ======================================================================
  643.       Example of "-info p" with "-mrhoist on"
  644.       ======================================================================
  645.         #if 0
  646.         Hoisting of predicate suppressed by alternative without predicate.
  647.         The alt without the predicate includes all cases where the
  648.            predicate is false.
  649.            WITH predicate: line 11  v36.g
  650.            WITHOUT predicate: line 12  v36.g
  651.         The context set for the predicate:
  652.              B
  653.         The lookahead set for alt WITHOUT the semantic predicate:
  654.              B
  655.         The predicate:
  656.           pred <<  LATEXT(1)>>?  depth=k=1  rule c  line 11  v36.g
  657.             set context:
  658.                B
  659.             tree context: null
  660.         Chain of referenced rules:
  661.             #0  in rule start (line 1 v36.g) to rule all
  662.             #1  in rule all (line 3 v36.g) to rule a
  663.             #2  in rule a (line 8 v36.g) to rule c
  664.             #3  in rule c (line 11 v36.g)
  665.         #endif
  666.         &&
  667.         #if 0
  668.         pred <<  LATEXT(1)>>?  depth=k=1  rule b  line 15  v36.g
  669.           set context:
  670.              X
  671.           tree context: null
  672.         #endif
  673.       ======================================================================
  674.       Example of "-info p"  with the default -prc setting ( "-prc off")
  675.       ======================================================================
  676.         #if 0
  677.         OR
  678.           pred <<  LATEXT(1)>>?  depth=k=1  rule c  line 11  v36.g
  679.             set context:
  680.               nil
  681.             tree context: null
  682.           pred <<  LATEXT(1)>>?  depth=k=1  rule b  line 15  v36.g
  683.             set context:
  684.               nil
  685.             tree context: null
  686.         #endif
  687.       ======================================================================
  688.       Example of "-info p" with "-prc on" and "-mrhoist off"
  689.       ======================================================================
  690.         #if 0
  691.         OR
  692.           pred <<  LATEXT(1)>>?  depth=k=1  rule c  line 11  v36.g
  693.             set context:
  694.                B
  695.             tree context: null
  696.           pred <<  LATEXT(1)>>?  depth=k=1  rule b  line 15  v36.g
  697.             set context:
  698.                X
  699.             tree context: null
  700.         #endif
  701.       ======================================================================
  702. #97.  (Fixed in 1.33MR10) "Predicate applied for more than one ... "
  703.       In 1.33 vanilla, the grammar listed below produced this message for
  704.       the first alternative (only) of rule "b":
  705.             warning: predicate applied for >1 lookahead 1-sequences
  706.                 [you may only want one lookahead 1-sequence to apply.
  707.                 Try using a context guard '(...)? =>'
  708.       In 1.33MR10 the message is issued for both alternatives.
  709.           top     : (a)*;
  710.           a       : b | c ;
  711.           b       : <<PPP(LATEXT(1))>>? ( AAA | BBB )
  712.                   | <<QQQ(LATEXT(1))>>? ( XXX | YYY )
  713.                   ;
  714.           c       : AAA | XXX;
  715. #96.  (Fixed in 1.33MR10) Guard predicates ignored when -prc off
  716.       Prior to 1.33MR10, guard predicate code was not generated unless
  717.       "-prc on" was selected.
  718.       This was incorrect, since "-prc off"  (the default) is supposed to
  719.       disable only AUTOMATIC computation of predicate context, not the
  720.       programmer specified context supplied by guard predicates.
  721. #95.  (Fixed in 1.33MR10) Predicate guard context length was k, not max(k,ck)
  722.       Prior to 1.33MR10, predicate guards were computed to k tokens rather
  723.       than max(k,ck).  Consider the following grammar:
  724.         a     : ( A B C)? => <<AAA(LATEXT(1))>>? (A|X) (B|Y) (C|Z) ;
  725.       The code generated by 1.33 vanilla with "-k 1 -ck 3 -prc on"
  726.       for the predicate in "a" resembles:
  727.         if ( (! LA(1)==A) || AAA(LATEXT(1))) {...
  728.       With 1.33MR10 and the same options the code resembles:
  729.         if ( (! (LA(1)==A && LA(2)==B && LA(3)==C) || AAA(LATEXT(1))) {...
  730. #94.  (Fixed in 1.33MR10) Predicates followed by rule references
  731.       Prior to 1.33MR10, a semantic predicate which referenced a token
  732.       which was off the end of the rule caused an incomplete context
  733.       to be computed (with "-prc on") for the predicate under some circum-
  734.       stances.  In some cases this manifested itself as illegal C code
  735.       (e.g. "LA(2)==[Ep](1)" in the k=2 examples below:
  736.           all     : ( a ) *;
  737.           a       : <<AAA(LATEXT(2))>>? ID X
  738.                   | <<BBB(LATEXT(2))>>? Y
  739.                   | Z
  740.                   ;
  741.       This might also occur when the semantic predicate was followed
  742.       by a rule reference which was shorter than the length of the
  743.       semantic predicate:
  744.         all       : ( a ) *;
  745.         a         : <<AAA(LATEXT(2))>>? ID X
  746.                   | <<BBB(LATEXT(2))>>? y
  747.                   | Z
  748.                   ;
  749.         y         : Y ;
  750.       Depending on circumstance, the resulting context might be too
  751.       generous because it was too short, or too restrictive because
  752.       of missing alternatives.
  753. #93.  (Changed in 1.33MR10) Definition of Purify macro
  754.       Ofer Ben-Ami (gremlin@cs.huji.ac.il) has supplied a definition
  755.       for the Purify macro:
  756.         #define PURIFY(r, s) memset((char *) &(r), '', (s));
  757.       Note: This may not be the right thing to do for C++ objects that
  758.       have constructors.  Reported by Bonny Rais (bonny@werple.net.au).
  759.       For those cases one should #define PURIFY to an empty macro in the
  760.       #header or #first actions.
  761. #92.  (Fixed in 1.33MR10) Guarded predicates and hoisting
  762.       When a guarded predicate participates in hoisting it is linked into
  763.       a predicate expression tree.  Prior to 1.33MR10 this link was never
  764.       cleared and the next time the guard was used to construct a new
  765.       tree the link could contain a spurious reference to another element
  766.       which had previosly been joined to it in the semantic predicate tree.
  767.       For example:
  768.         start  : ( all ) *;
  769.         all    : ( a | b ) ;
  770.         start2 : ( all2 ) *;
  771.         all2    : ( a ) ;
  772.         a     : (A)? => <<AAA(LATEXT(1))>>?  A ;
  773.         b     : (B)? => <<BBB(LATEXT(1))>>?  B ;
  774.       Prior to 1.33MR10 the code for "start2" would include a spurious
  775.       reference to the BBB predicate which was left from constructing
  776.       the predicate tree for rule "start" (i.e. or(AAA,BBB) ).
  777.       In 1.33MR10 this problem is avoided by cloning the original guard
  778.       each time it is linked into a predicate tree.
  779. #91.  (Changed in 1.33MR10) Extensive changes to semantic pred hoisting
  780.             ============================================
  781.             This has been rendered obsolete by Item #117
  782.             ============================================
  783. #90.  (Fixed in 1.33MR10) Semantic pred with LT(i) and i>max(k,ck)
  784.       There is a bug in antlr 1.33 vanilla and all maintenance releases
  785.       prior to 1.33MR10 which allows semantic predicates to reference
  786.       an LT(i) or LATEXT(i) where i is larger than max(k,ck).  When
  787.       this occurs antlr will attempt to mark the ith element of an array
  788.       in which there are only max(k,ck) elements.  The result cannot
  789.       be predicted.
  790.       Using LT(i) or LATEXT(i) for i>max(k,ck) is reported as an error
  791.       in 1.33MR10.
  792. #89.  Rescinded
  793. #88.  (Fixed in 1.33MR10) Tokens used in semantic predicates in guess mode
  794.         Consider the behavior of a semantic predicate during guess mode:
  795.             rule : a:A (
  796.                          <<test($a)>>? b:B
  797.                          | c:C
  798.                        );
  799.         Prior to MR10 the assignment of the token or attribute to
  800.         $a did not occur during guess mode, which would cause the
  801.         semantic predicate to misbehave because $a would be null.
  802.         In 1.33MR10 a semantic predicate with a reference to an
  803.         element label (such as $a) forces the assignment to take
  804.         place even in guess mode.
  805.         In order to work, this fix REQUIRES use of the $label format
  806.         for token pointers and attributes referenced in semantic
  807.         predicates.
  808.         The fix does not apply to semantic predicates using the
  809.         numeric form to refer to attributes (e.g. <<test($1)>>?).
  810.         The user will receive a warning for this case.
  811.         Reported by Rob Trout (trout@mcs.cs.kent.edu).
  812. #87.  (Fixed in 1.33MR10) Malformed guard predicates
  813.       Context guard predicates may contain only references to
  814.       tokens.  They may not contain references to (...)+ and
  815.       (...)* blocks.  This is now checked.  This replaces the
  816.       fatal error message in item #78 with an appropriate
  817.       (non-fatal) error messge.
  818.       In theory, context guards should be allowed to reference
  819.       rules.  However, I have not had time to fix this.
  820.       Evaluation of the guard takes place before all rules have
  821.       been read, making it difficult to resolve a forward reference
  822.       to rule "zzz" - it hasn't been read yet !  To postpone evaluation
  823.       of the guard until all rules have been read is too much
  824.       for the moment.
  825. #86.  (Fixed in 1.33MR10) Unequal set size in set_sub
  826.       Routine set_sub() in pccts/support/set/set.h  did not work
  827.       correctly when the sets were of unequal sizes.  Rewrote
  828.       set_equ to make it simpler and remove unnecessary and
  829.       expensive calls to set_deg().  This routine was not used
  830.       in 1.33 vanila.
  831. #85.  (Changed in 1.33MR10) Allow redefinition of MaxNumFiles
  832.       Raised the maximum number of input files to 99 from 20.
  833.       Put a #ifndef/#endif around the "#define MaxNumFiles 99".
  834. #84.  (Fixed in 1.33MR10) Initialize zzBadTok in macro zzRULE
  835.       Initialize zzBadTok to NULL in zzRULE macro of AParser.h.
  836.       in order to get rid of warning messages.
  837. #83.  (Fixed in 1.33MR10) False warnings with -w2 for #tokclass
  838.       When -w2 is selected antlr gives inappropriate warnings about
  839.       #tokclass names not having any associated regular expressions.
  840.       Since a #tokclass is not a "real" token it will never have an
  841.       associated regular expression and there should be no warning.
  842.       Reported by Derek Pappas (derek.pappas@eng.sun.com)
  843. #82.  (Fixed in 1.33MR10) Computation of follow sets with multiple cycles
  844.       Reinier van den Born (reinier@vnet.ibm.com) reported a problem
  845.       in the computation of follow sets by antlr.  The problem (bug)
  846.       exists in 1.33 vanilla and all maintenance releases prior to 1.33MR10.
  847.       The problem involves the computation of follow sets when there are
  848.       cycles - rules which have mutual references.  I believe the problem
  849.       is restricted to cases where there is  more than one cycle AND
  850.       elements of those cycles have rules in common.  Even when this
  851.       occurs it may not affect the code generated - but it might.  It
  852.       might also lead to undetected ambiguities.
  853.       There were no changes in antlr or dlg output from the revised version.
  854.       The following fragment demonstates the problem by giving different
  855.       follow sets (option -pa) for var_access when built with k=1 and ck=2 on
  856.       1.33 vanilla and 1.33MR10:
  857.         echo_statement : ECHO ( echo_expr )*
  858.                        ;
  859.         echo_expr      : ( command )?
  860.                        | expression
  861.                        ;
  862.         command        : IDENTIFIER
  863.                              { concat }
  864.                        ;
  865.         expression     : operand ( OPERATOR operand )*
  866.                        ;
  867.         operand        : value
  868.                        | START command END
  869.                        ;
  870.         value          : concat
  871.                        | TYPE operand
  872.                        ;
  873.         concat         : var_access { CONCAT value }
  874.                        ;
  875.         var_access     : IDENTIFIER { INDEX }
  876.                        ;
  877. #81.  (Changed in 1.33MR10) C mode use of attributes and ASTs
  878.        Reported by Isaac Clark (irclark@mindspring.com).
  879.        C mode code ignores attributes returned by rules which are
  880.        referenced using element labels when ASTs are enabled (-gt option).
  881.          1. start : r:rule t:Token <<$start=$r;>>
  882.                 The $r refrence will not work when combined with
  883.                 the -gt option.
  884.          2. start : t:Token         <<$start=$t;>>
  885.                 The $t reference works in all cases.
  886.          3. start : rule            <<$0=$1;>>
  887.                 Numeric labels work in all cases.
  888.        With MR10 the user will receive an error message for case 1 when
  889.        the -gt option is used.
  890. #80.  (Fixed in 1.33MR10) (...)? as last alternative of block
  891.         A construct like the following:
  892.             rule : a
  893.                  | (b)?
  894.                  ;
  895.         does not make sense because there is no alternative when
  896.         the guess block fails.  This is now reported as a warning
  897.         to the user.
  898.         Previously, there was a code generation error for this case:
  899.         the guess block was not "closed"  when the guess failed.
  900.         This could cause an infinite loop or other problems.  This
  901.         is now fixed.
  902.         Example problem:
  903.             #header<<
  904.             #include <stdio.h>
  905.             #include "charptr.h"
  906.             >>
  907.             <<
  908.             #include "charptr.c"
  909.             main ()
  910.             {
  911.              ANTLR(start(),stdin);
  912.             }
  913.             >>
  914.             #token "[ t]+"        << zzskip(); >>
  915.             #token "[n]"           << zzline++; zzskip(); >>
  916.             #token Word     "[a-z]+"
  917.             #token Number   "[0-9]+"
  918.             start : (test1)?
  919.                   | (test2)?
  920.                   ;
  921.             test1 : (Word Word Word Word)?
  922.                   | (Word Word Word Number)?
  923.                   ;
  924.             test2 : (Word Word Number Word)?
  925.                   | (Word Word Number Number)?
  926.             ;
  927.         Test data which caused infinite loop:
  928.             a 1 a a
  929. #79.  (Changed in 1.33MR10) Use of -fh with multiple parsers
  930.         Previously, antlr always used the pre-processor symbol
  931.         STDPCCTS_H as a gate for the file stdpccts.h.  This
  932.         caused problems when there were multiple parsers defined
  933.         because they used the same gate symbol.
  934.         In 1.33MR10, the -fh filename is used to generate the
  935.         gate file for stdpccts.h.  For instance:
  936.             antlr -fh std_parser1.h
  937.         generates the pre-processor symbol "STDPCCTS_std_parser1_H".
  938.         Reported by Ramanathan Santhanam (ps@kumaran.com).
  939. #78.  (Changed in 1.33MR9) Guard predicates that refer to rules
  940.                 ------------------------
  941.                 Please refer to Item #87
  942.                 ------------------------
  943.         Guard predicates are processed during an early phase
  944.         of antlr (during parsing) before all data structures
  945.         are completed.
  946.         There is an apparent bug in earlier versions of 1.33
  947.         which caused guard predicates which contained references
  948.         to rules (rather than tokens) to reference a structure
  949.         which hadn't yet been initialized.
  950.         In some cases (perhaps all cases) references to rules
  951.         in guard predicates resulted in the use of "garbage".
  952. #79.  (Changed in 1.33MR9) Jeff Vincent (JVincent@novell.com)
  953.         Previously, the maximum length file name was set
  954.         arbitrarily to 300 characters in antlr, dlg, and sorcerer.
  955.         The config.h file now attempts to define the maximum length
  956.         filename using _MAX_PATH from stdlib.h before falling back
  957.         to using the value 300.
  958. #78.  (Changed in 1.33MR9) Jeff Vincent (JVincent@novell.com)
  959.         Put #ifndef/#endif around definition of ZZLEXBUFSIZE in
  960.         antlr.
  961. #77.  (Changed in 1.33MR9) Arithmetic overflow for very large grammars
  962.         In routine HandleAmbiguities() antlr attempts to compute the
  963.         number of possible elements in a set that is order of
  964.         number-of-tokens raised to the number-of-lookahead-tokens power.
  965.         For large grammars or large lookahead (e.g. -ck 7) this can
  966.         cause arithmetic overflow.
  967.         With 1.33MR9, arithmetic overflow in this computation is reported
  968.         the first time it happens.  The program continues to run and
  969.         the program branches based on the assumption that the computed
  970.         value is larger than any number computed by counting actual cases
  971.         because 2**31 is larger than the number of bits in most computers.
  972.         Before 1.33MR9 overflow was not reported.  The behavior following
  973.         overflow is not predictable by anyone but the original author.
  974.                             NOTE
  975.             In 1.33MR10 the warning message is suppressed.
  976.             The code which detects the overflow allows the
  977.             computation to continue without an error.  The
  978.             error message itself made made users worry.
  979. #76.  (Changed in 1.33MR9) Jeff Vincent (JVincent@novell.com)
  980.         Jeff Vincent has convinced me to make ANTLRCommonToken and
  981.         ANTLRCommonNoRefCountToken use variable length strings
  982.         allocated from the heap rather than fixed length strings.
  983.         By suitable definition of setText(), the copy constructor,
  984.         and operator =() it is possible to maintain "copy" semantics.
  985.         By "copy" semantics I mean that when a token is copied from
  986.         an existing token it receives its own, distinct, copy of the
  987.         text allocated from the heap rather than simply a pointer
  988.         to the original token's text.
  989.         ============================================================
  990.                         W * A * R * N * I * N * G
  991.         ============================================================
  992.         It is possible that this may cause problems for some users.
  993.         For those users I have included the old version of AToken.h as
  994.         pccts/h/AToken_traditional.h.
  995. #75.  (Changed in 1.33MR9) Bruce Guenter (bruceg@qcc.sk.ca)
  996.         Make DLGStringInput const correct.  Since this is infrequently
  997.         subclassed, it should affect few users, I hope.
  998. #74.  (Changed in 1.33MR9) -o (output directory) option
  999.         Antlr does not properly handle the -o output directory option
  1000.         when the filename of the grammar contains a directory part.  For
  1001.         example:
  1002.             antlr -o outdir pccts_src/myfile.g
  1003.         causes antlr create a file called "outdir/pccts_src/myfile.cpp.
  1004.         It SHOULD create outdir/myfile.cpp
  1005.         The suggested code fix has been installed in antlr, dlg, and
  1006.         Sorcerer.
  1007. #73.  (Changed in 1.33MR9) Hoisting of semantic predicates and -mrhoist
  1008.             ============================================
  1009.             This has been rendered obsolete by Item #117
  1010.             ============================================
  1011. #72.  (Changed in 1.33MR9) virtual saveState()/restoreState()/guess_XXX
  1012.         The following methods in ANTLRParser were made virtual at
  1013.         the request of S. Bochnak (S.Bochnak@microTool.com.pl):
  1014.             saveState() and restoreState()
  1015.             guess(), guess_fail(), and guess_done()
  1016. #71.  (Changed in 1.33MR9) Access to omitted command line argument
  1017.         If a switch requiring arguments is the last thing on the
  1018.         command line, and the argument is omitted, antlr would core.
  1019.             antlr test.g -prc
  1020.         instead of
  1021.             antlr test.g -prc off
  1022. #70.  (Changed in 1.33MR9) Addition of MSVC .dsp and .mak build files
  1023.         The following MSVC .dsp and .mak files for pccts and sorcerer
  1024.         were contributed by Stanislaw Bochnak (S.Bochnak@microTool.com.pl)
  1025.         and Jeff Vincent (JVincent@novell.com)
  1026.         PCCTS Distribution Kit
  1027.         ----------------------
  1028.         pccts/PCCTSMSVC50.dsw
  1029.         pccts/antlr/AntlrMSVC50.dsp
  1030.         pccts/antlr/AntlrMSVC50.mak
  1031.         pccts/dlg/DlgMSVC50.dsp
  1032.         pccts/dlg/DlgMSVC50.mak
  1033.         pccts/support/msvc.dsp
  1034.         Sorcerer Distribution Kit
  1035.         -------------------------
  1036.         pccts/sorcerer/SorcererMSVC50.dsp
  1037.         pccts/sorcerer/SorcererMSVC50.mak
  1038.         pccts/sorcerer/lib/msvc.dsp
  1039. #69.  (Changed in 1.33MR9) Change "unsigned int" to plain "int"
  1040.        Declaration of max_token_num in misc.c as "unsigned int"
  1041.        caused comparison between signed and unsigned ints giving
  1042.        warning message without any special benefit.
  1043. #68.  (Changed in 1.33MR9) Add void return for dlg internal_error()
  1044.        Get rid of "no return value" message in internal_error()
  1045.        in file dlg/support.c and dlg/dlg.h.
  1046. #67.  (Changed in Sor) sor.g: lisp() has no return value
  1047.        Added a "void" for the return type.
  1048. #66.  (Added to Sor) sor.g: ZZLEXBUFSIZE enclosed in #ifndef/#endif
  1049.        A user needed to be able to change the ZZLEXBUFSIZE for
  1050.        sor. Put the definition of ZZLEXBUFSIZE inside #ifndef/#endif
  1051. #65.  (Changed in 1.33MR9) PCCTSAST::deepCopy() and ast_dup() bug
  1052.        Jeff Vincent (JVincent@novell.com) found that deepCopy()
  1053.        made new copies of only the direct descendents.  No new
  1054.        copies were made of sibling nodes,  Sibling pointers are
  1055.        set to zero by shallowCopy().
  1056.            PCCTS_AST::deepCopy() has been changed to make a
  1057.            deep copy in the traditional sense.
  1058.            The deepCopy() routine depends on the behavior of
  1059.            shallowCopy().  In all sor examples I've found,
  1060.            shallowCopy() zeroes the right and down pointers.
  1061.        Original Tree       Original deepCopy()     Revised deepCopy
  1062.        -------------       -------------------     ----------------
  1063.             a->b->c         A                       A
  1064.             |               |                       |
  1065.             d->e->f         D                       D->E->F
  1066.             |               |                       |
  1067.             g->h->i         G                       G->H->I
  1068.                |                                       |
  1069.                j->k                                    J->K
  1070.         While comparing deepCopy() for C++ mode with ast_dup for
  1071.         C mode I found a problem with ast_dup().
  1072.            Routine ast_dup() has been changed to make a deep copy
  1073.            in the traditional sense.
  1074.        Original Tree       Original ast_dup()      Revised ast_dup()
  1075.        -------------       -------------------     ----------------
  1076.             a->b->c         A->B->C                 A
  1077.             |               |                       |
  1078.             d->e->f         D->E->F                 D->E->F
  1079.             |               |                       |
  1080.             g->h->i         G->H->I                 G->H->I
  1081.                |               |                       |
  1082.                j->k            J->K                    J->K
  1083.         I believe this affects transform mode sorcerer programs only.
  1084. #64.  (Changed in 1.33MR9) anltr/hash.h prototype for killHashTable()
  1085. #63.  (Changed in 1.33MR8) h/charptr.h does not zero pointer after free
  1086.         The charptr.h routine now zeroes the pointer after free().
  1087.         Reported by Jens Tingleff (jensting@imaginet.fr)
  1088. #62.  (Changed in 1.33MR8) ANTLRParser::resynch had static variable
  1089.         The static variable "consumed" in ANTLRParser::resynch was
  1090.         changed into an instance variable of the class with the
  1091.         name "resynchConsumed".
  1092.         Reported by S.Bochnak@microTool.com.pl
  1093. #61.  (Changed in 1.33MR8) Using rule>[i,j] when rule has no return values
  1094.         Previously, the following code would cause antlr to core when
  1095.         it tried to generate code for rule1 because rule2 had no return
  1096.         values ("upward inheritance"):
  1097.             rule1 : <<int i; int j>>
  1098.                     rule2 > [i,j]
  1099.                   ;
  1100.             rule2 : Anything ;
  1101.         Reported by S.Bochnak@microTool.com.pl
  1102.         Verified correct operation of antlr MR8 when missing or extra
  1103.         inheritance arguments for all combinations.  When there are
  1104.         missing or extra arguments code will still be generated even
  1105.         though this might cause the invocation of a subroutine with
  1106.         the wrong number of arguments.
  1107. #60.  (Changed in 1.33MR7) Major changes to exception handling
  1108.         There were significant problems in the handling of exceptions
  1109.         in 1.33 vanilla.  The general problem is that it can only
  1110.         process one level of exception handler.  For example, a named
  1111.         exception handler, an exception handler for an alternative, or
  1112.         an exception for a subrule  always went to the rule's exception
  1113.         handler if there was no "catch" which matched the exception.
  1114.         In 1.33MR7 the exception handlers properly "nest".  If an
  1115.         exception handler does not have a matching "catch" then the
  1116.         nextmost outer exception handler is checked for an appropriate
  1117.         "catch" clause, and so on until an exception handler with an
  1118.         appropriate "catch" is found.
  1119.         There are still undesirable features in the way exception
  1120.         handlers are implemented, but I do not have time to fix them
  1121.         at the moment:
  1122.             The exception handlers for alternatives are outside the
  1123.             block containing the alternative.  This makes it impossible
  1124.             to access variables declared in a block or to resume the
  1125.             parse by "falling through".  The parse can still be easily
  1126.             resumed in other ways, but not in the most natural fashion.
  1127.             This results in an inconsistentcy between named exception
  1128.             handlers and exception handlers for alternatives.  When
  1129.             an exception handler for an alternative "falls through"
  1130.             it goes to the nextmost outer handler - not the "normal
  1131.             action".
  1132.         A major difference between 1.33MR7 and 1.33 vanilla is
  1133.         the default action after an exception is caught:
  1134.             1.33 Vanilla
  1135.             ------------
  1136.             In 1.33 vanilla the signal value is set to zero ("NoSignal")
  1137.             and the code drops through to the code following the exception.
  1138.             For named exception handlers this is the "normal action".
  1139.             For alternative exception handlers this is the rule's handler.
  1140.             1.33MR7
  1141.             -------
  1142.             In 1.33MR7 the signal value is NOT automatically set to zero.
  1143.             There are two cases:
  1144.                 For named exception handlers: if the signal value has been
  1145.                 set to zero the code drops through to the "normal action".
  1146.                 For all other cases the code branches to the nextmost outer
  1147.                 exception handler until it reaches the handler for the rule.
  1148.         The following macros have been defined for convenience:
  1149.             C/C++ Mode Name
  1150.             --------------------
  1151.             (zz)suppressSignal
  1152.                   set signal & return signal arg to 0 ("NoSignal")
  1153.             (zz)setSignal(intValue)
  1154.                   set signal & return signal arg to some value
  1155.             (zz)exportSignal
  1156.                   copy the signal value to the return signal arg
  1157.         I'm not sure why PCCTS make a distinction between the local
  1158.         signal value and the return signal argument, but I'm loathe
  1159.         to change the code. The burden of copying the local signal
  1160.         value to the return signal argument can be given to the
  1161.         default signal handler, I suppose.
  1162. #59.  (Changed in 1.33MR7) Prototypes for some functions
  1163.         Added prototypes for the following functions to antlr.h
  1164.             zzconsumeUntil()
  1165.             zzconsumeUntilToken()
  1166. #58.  (Changed in 1.33MR7) Added defintion of zzbufsize to dlgauto.h
  1167. #57.  (Changed in 1.33MR7) Format of #line directive
  1168.         Previously, the -gl directive for line 1234 would
  1169.         resemble:  "# 1234 filename.g".  This caused problems
  1170.         for some compilers/pre-processors.  In MR7 it generates
  1171.         "#line 1234 filename.g".
  1172. #56.  (Added in 1.33MR7) Jan Mikkelsen <janm@zeta.org.au>
  1173.         Move PURIFY macro invocaton to after rule's init action.
  1174. #55.  (Fixed in 1.33MR7) Unitialized variables in ANTLRParser
  1175.         Member variables inf_labase and inf_last were not initialized.
  1176.         (See item #50.)
  1177. #54.  (Fixed in 1.33MR6) Brad Schick (schick@interacess.com)
  1178.         Previously, the following constructs generated the same
  1179.         code:
  1180.         rule1 : (A B C)?
  1181.               | something-else
  1182.               ;
  1183.         rule2 : (A B C)? ()
  1184.               | something-else
  1185.               ;
  1186.         In all versions of pccts rule1 guesses (A B C) and then
  1187.         consume all three tokens if the guess succeeds.  In MR6
  1188.         rule2 guesses (A B C)  but consumes NONE of the tokens
  1189.         when the guess succeeds because "()" matches epsilon.
  1190. #53.  (Explanation for 1.33MR6) What happens after an exception is caught ?
  1191.         The Book is silent about what happens after an exception
  1192.         is caught.
  1193.         The following code fragment prints "Error Action" followed
  1194.         by "Normal Action".
  1195.         test : Word ex:Number <<printf("Normal Actionn");>>
  1196.                 exception[ex]
  1197.                    catch NoViableAlt:
  1198.                         <<printf("Error Actionn");>>
  1199.         ;
  1200.         The reason for "Normal Action" is that the normal flow of the
  1201.         program after a user-written exception handler is to "drop through".
  1202.         In the case of an exception handler for a rule this results in
  1203.         the exection of a "return" statement.  In the case of an
  1204.         exception handler attached to an alternative, rule, or token
  1205.         this is the code that would have executed had there been no
  1206.         exception.
  1207.         The user can achieve the desired result by using a "return"
  1208.         statement.
  1209.         test : Word ex:Number <<printf("Normal Actionn");>>
  1210.                 exception[ex]
  1211.                    catch NoViableAlt:
  1212.                         <<printf("Error Actionn"); return;>>
  1213.         ;
  1214.         The most powerful mechanism for recovery from parse errors
  1215.         in pccts is syntactic predicates because they provide
  1216.         backtracking.  Exceptions allow "return", "break",
  1217.         "consumeUntil(...)", "goto _handler", "goto _fail", and
  1218.         changing the _signal value.
  1219. #52.  (Fixed in 1.33MR6) Exceptions without syntactic predicates
  1220.         The following generates bad code in 1.33 if no syntactic
  1221.         predicates are present in the grammar.
  1222.         test : Word ex:Number <<printf("Normal Actionn");>>
  1223.                 exception[ex]
  1224.                    catch NoViableAlt:
  1225.                         <<printf("Error Actionn");>>
  1226.         There is a reference to a guess variable.  In C mode
  1227.         this causes a compiler error.  In C++ mode it generates
  1228.         an extraneous check on member "guessing".
  1229.         In MR6 correct code is generated for both C and C++ mode.
  1230. #51.  (Added to 1.33MR6) Exception operator "@" used without exceptions
  1231.         In MR6 added a warning when the exception operator "@" is
  1232.         used and no exception group is defined.  This is probably
  1233.         a case where "@" or "@" is meant.
  1234. #50.  (Fixed in 1.33MR6) Gunnar Rxnning (gunnar@candleweb.no)
  1235.                                     http://www.candleweb.no/~gunnar/
  1236.         Routines zzsave_antlr_state and zzrestore_antlr_state don't
  1237.         save and restore all the data needed when switching states.
  1238.         Suggested patch applied to antlr.h and err.h for MR6.
  1239. #49.  (Fixed in 1.33MR6) Sinan Karasu (sinan@boeing.com)
  1240.         Generated code failed to turn off guess mode when leaving a
  1241.         (...)+ block which contained a guess block.  The result was
  1242.         an infinite loop.  For example:
  1243.                 rule : (
  1244.                          (x)?
  1245.                          | y
  1246.                        )+
  1247.         Suggested code fix implemented in MR6.  Replaced
  1248.             ... else if (zzcnt>1) break;
  1249.         with:
  1250.           C++ mode:
  1251.               ... else if (zzcnt>1) {if (!zzrv) zzGUESS_DONE; break;};
  1252.           C mode:
  1253.               ... else if (zzcnt>1) {if (zzguessing) zzGUESS_DONE; break;};
  1254. #48.  (Fixed in 1.33MR6) Invalid exception element causes core
  1255.         A label attached to an invalid construct can cause
  1256.         pccts to crash while processing the exception associated
  1257.         with the label.  For example:
  1258.         rule : t:(B C)
  1259.                 exception[t] catch MismatchedToken: <<printf(...);>>
  1260.         Version MR6 generates the message:
  1261.            reference in exception handler to undefined label 't'
  1262. #47.  (Fixed in 1.33MR6) Manuel Ornato
  1263.         Under some circumstances involving a k >1 or ck >1
  1264.         grammar and a loop block (i.e.  (...)* ) pccts will
  1265.         fail to detect a syntax error and loop indefinitely.
  1266.         The problem did not exist in 1.20, but has existed
  1267.         from 1.23 to the present.
  1268.         Fixed in MR6.
  1269.         ---------------------------------------------------
  1270.         Complete test program
  1271.         ---------------------------------------------------
  1272.         #header<<
  1273.         #include <stdio.h>
  1274.         #include "charptr.h"
  1275.         >>
  1276.         <<
  1277.         #include "charptr.c"
  1278.         main ()
  1279.         {
  1280.          ANTLR(global(),stdin);
  1281.         }
  1282.         >>
  1283.         #token "[ t]+"        << zzskip(); >>
  1284.         #token "[n]"           << zzline++; zzskip(); >>
  1285.         #token B        "b"
  1286.         #token C        "c"
  1287.         #token D        "d"
  1288.         #token E        "e"
  1289.         #token LP       "("
  1290.         #token RP       ")"
  1291.         #token ANTLREOF "@"
  1292.         global : (
  1293.                    (E liste)
  1294.                  | liste
  1295.                  | listed
  1296.                  )  ANTLREOF
  1297.         ;
  1298.         listeb : LP ( B ( B | C )* ) RP ;
  1299.         listec : LP ( C ( B | C )* ) RP ;
  1300.         listed : LP ( D ( B | C )* ) RP ;
  1301.         liste : ( listeb | listec )* ;
  1302.         ---------------------------------------------------
  1303.         Sample data causing infinite loop
  1304.         ---------------------------------------------------
  1305.         e (d c)
  1306.         ---------------------------------------------------
  1307. #46.  (Fixed in 1.33MR6) Robert Richter
  1308.                 (Robert.Richter@infotech.tu-chemnitz.de)
  1309.         This item from the list of known problems was
  1310.         fixed by item #18 (below).
  1311. #45.  (Fixed in 1.33MR6) Brad Schick (schick@interaccess.com)
  1312.         The dependency scanner in VC++ mistakenly sees a
  1313.         reference to an MPW #include file even though properly
  1314.         #ifdef/#endif in config.h.  The suggested workaround
  1315.         has been implemented:
  1316.                 #ifdef MPW
  1317.                 .....
  1318.                 #define MPW_CursorCtl_Header <CursorCtl.h>
  1319.                 #include MPW_CursorCtl_Header
  1320.                 .....
  1321.                 #endif
  1322. #44.  (Fixed in 1.33MR6) cast malloc() to (char *) in charptr.c
  1323.         Added (char *) cast for systems where malloc returns "void *".
  1324. #43.  (Added to 1.33MR6) Bruce Guenter (bruceg@qcc.sk.ca)
  1325.         Add setLeft() and setUp methods to ASTDoublyLinkedBase
  1326.         for symmetry with setRight() and setDown() methods.
  1327. #42.  (Fixed in 1.33MR6) Jeff Katcher (jkatcher@nortel.ca)
  1328.         C++ style comment in antlr.c corrected.
  1329. #41.  (Added in 1.33MR6) antlr -stdout
  1330.         Using "antlr -stdout ..." forces the text that would
  1331.         normally go to the grammar.c or grammar.cpp file to
  1332.         stdout.
  1333. #40.  (Added in 1.33MR6) antlr -tab to change tab stops
  1334.         Using "antlr -tab number ..." changes the tab stops
  1335.         for the grammar.c or grammar.cpp file.  The number
  1336.         must be between 0 and 8.  Using 0 gives tab characters,
  1337.         values between 1 and 8 give the appropriate number of
  1338.         space characters.
  1339. #39.  (Fixed in 1.33MR5) Jan Mikkelsen <janm@zeta.org.au>
  1340.         Commas in function prototype still not correct under
  1341.         some circumstances.  Suggested code fix installed.
  1342. #38.  (Fixed in 1.33MR5) ANTLRTokenBuffer constructor
  1343.         Have ANTLRTokenBuffer ctor initialize member "parser" to null.
  1344. #37.  (Fixed in 1.33MR4) Bruce Guenter (bruceg@qcc.sk.ca)
  1345.         In ANTLRParser::FAIL(int k,...) released memory pointed to by
  1346.         f[i] (as well as f itself.  Should only free f itself.
  1347. #36.  (Fixed in 1.33MR3) Cortland D. Starrett (cort@shay.ecn.purdue.edu)
  1348.         Neglected to properly declare isDLGmaxToken() when fixing problem
  1349.         reported by Andreas Magnusson.
  1350.         Undo "_retv=NULL;" change which caused problems for return values
  1351.         from rules whose return values weren't pointers.
  1352.         Failed to create bin directory if it didn't exist.
  1353. #35.  (Fixed in 1.33MR2) Andreas Magnusson
  1354. (Andreas.Magnusson@mailbox.swipnet.se)
  1355.         Repair bug introduced by 1.33MR1 for #tokdefs.  The original fix
  1356.         placed "DLGmaxToken=9999" and "DLGminToken=0" in the TokenType enum
  1357.         in order to fix a problem with an aggresive compiler assigning an 8
  1358.         bit enum which might be too narrow.  This caused #tokdefs to assume
  1359.         that there were 9999 real tokens.  The repair to the fix causes antlr to
  1360.         ignore TokenTypes "DLGmaxToken" and "DLGminToken" in a #tokdefs file.
  1361. #34.  (Added to 1.33MR1) Add public DLGLexerBase::set_line(int newValue)
  1362.         Previously there was no public function for changing the line
  1363.         number maintained by the lexer.
  1364. #33.  (Fixed in 1.33MR1) Franklin Chen   (chen@adi.com)
  1365.         Accidental use of EXIT_FAILURE rather than PCCTS_EXIT_FAILURE
  1366.         in pccts/h/AParser.cpp.
  1367. #32.  (Fixed in 1.33MR1) Franklin Chen   (chen@adi.com)
  1368.         In PCCTSAST.cpp lines 405 and 466:  Change
  1369.                 free (t)
  1370.            to
  1371.                 free ( (char *)t );
  1372.         to match prototype.
  1373. #31.   (Added to 1.33MR1) Pointer to parser in ANTLRTokenBuffer
  1374.                         Pointer to parser in DLGLexerBase
  1375.         The ANTLRTokenBuffer class now contains a pointer to the
  1376.         parser which is using it.  This is established by the
  1377.         ANTLRParser constructor calling ANTLRTokenBuffer::
  1378.         setParser(ANTLRParser *p).
  1379.         When ANTLRTokenBuffer::setParser(ANTLRParser *p) is
  1380.         called it saves the pointer to the parser and then
  1381.         calls ANTLRTokenStream::setParser(ANTLRParser *p)
  1382.         so that the lexer can also save a pointer to the
  1383.         parser.
  1384.         There is also a function getParser() in each class
  1385.         with the obvious purpose.
  1386.         It is possible that these functions will return NULL
  1387.         under some circumstances (e.g. a non-DLG lexer is used).
  1388. #30.   (Added to 1.33MR1) function tokenName(int token) standard
  1389.         The generated parser class now includes the
  1390.         function:
  1391.           static const ANTLRChar * tokenName(int token)
  1392.         which returns a pointer to the "name" corresponding
  1393.         to the token.
  1394.         The base class (ANTLRParser) always includes the
  1395.         member function:
  1396.           const ANTLRChar * parserTokenName(int token)
  1397.         which can be accessed by objects which have a pointer
  1398.         to an ANTLRParser, but do not know the name of the
  1399.         parser class (e.g. ANTLRTokenBuffer and DLGLexerBase).
  1400. #29.   (Added to 1.33MR1) Debugging DLG lexers
  1401.         If the pre-processor symbol DEBUG_LEXER is defined
  1402.         then DLexerBase will include code for printing out
  1403.         key information about tokens which are recognized.
  1404.         The debug feature of the lexer is controlled by:
  1405.           int previousDebugValue=lexer.debugLexer(newValue);
  1406.                         a value of 0 disables output
  1407.                         a value of 1 enables output
  1408.         Even if the lexer debug code is compiled into DLexerBase
  1409.         it must be enabled before any output is generated.  For
  1410.         example:
  1411.            DLGFileInput         in(stdin);
  1412.            MyDLG                lexer(&in,2000);
  1413.            lexer.setToken(&aToken);
  1414.            #if DEBUG_LEXER
  1415.              lexer.debugLexer(1);       // enable debug information
  1416.            #endif
  1417. #28.   (Added to 1.33MR1) More control over DLG header
  1418.         Version 1.33MR1 adds the following directives to PCCTS
  1419.         for C++ mode:
  1420.           #lexprefix  <<source code>>
  1421.                 Adds source code to the DLGLexer.h file
  1422.                 after the #include "DLexerBase.h" but
  1423.                 before the start of the class definition.
  1424.           #lexmember  <<source code>>
  1425.                 Adds source code to the DLGLexer.h file
  1426.                 as part of the DLGLexer class body.  It
  1427.                 appears immediately after the start of
  1428.                 the class and a "public: statement.
  1429. #27.   (Fixed in 1.33MR1) Comments in DLG actions
  1430.         Previously, DLG would not recognize comments as a special case.
  1431.         Thus, ">>" in the comments would cause errors.  This is fixed.
  1432. #26.   (Fixed in 1.33MR1) Removed static variables from error routines
  1433.         Previously, the existence of statically allocated variables
  1434.         in some of the parser's member functions posed a danger when
  1435.         there was more than one parser active.
  1436.         Replaced with dynamically allocated/freed variables in 1.33MR1.
  1437. #25.  (Fixed in 1.33MR1)  Use of string literals in semantic predicates
  1438.         Previously, it was not possible to place a string literal in
  1439.         a semantic predicate because it was not properly "stringized"
  1440.         for the report of a failed predicate.
  1441. #24.  (Fixed in 1.33MR1)  Continuation lines for semantic predicates
  1442.         Previously, it was not possible to continue semantic
  1443.         predicates across a line because it was not properly
  1444.         "stringized" for the report of a failed predicate.
  1445.                 rule : <<ifXYZ()>>?[ a very
  1446.                                         long statement ]
  1447. #23.  (Fixed in 1.33MR1)  {...} envelope for failed semantic predicates
  1448.         Previously, there was a code generation error for failed
  1449.         semantic predicates:
  1450.           rule : <<xyz()>>?[ stmt1; stmt2; ]
  1451.         which generated code which resembled:
  1452.           if (! xyz()) stmt1; stmt2;
  1453.         It now puts the statements in a {...} envelope:
  1454.           if (! xyz()) { stmt1; stmt2; };
  1455. #22.  (Fixed in 1.33MR1)  Continuation of #token across lines using ""
  1456.         Previously, it was not possible to continue a #token regular
  1457.         expression across a line.  The trailing "" and newline caused
  1458.         a newline to be inserted into the regular expression by DLG.
  1459.         Fixed in 1.33MR1.
  1460. #21.  (Fixed in 1.33MR1)  Use of ">>" (right shift operator in DLG actions
  1461.         It is now possible to use the C++ right shift operator ">>"
  1462.         in DLG actions by using the normal escapes:
  1463.                 #token "shift-right"     << value=value >> 1;>>
  1464. #20.  (Version 1.33/19-Jan-97 Karl Eccleson <karle@microrobotics.co.uk>
  1465.                             P.A. Keller (P.A.Keller@bath.ac.uk)
  1466.         There is a problem due to using exceptions with the -gh option.
  1467.         Suggested fix now in 1.33MR1.
  1468. #19.  (Fixed in 1.33MR1)             Tom Piscotti and John Lilley
  1469.         There were problems suppressing messages to stdin and stdout
  1470.         when running in a window environment because some functions
  1471.         which uses fprint were not virtual.
  1472.         Suggested change now in 1.33MR1.
  1473.         I believe all functions containing error messages (excluding those
  1474.         indicating internal inconsistency) have been placed in functions
  1475.         which are virtual.
  1476. #18.  (Version 1.33/ 22-Nov-96)  John Bair (jbair@iftime.com)
  1477.         Under some combination of options a required "return _retv" is
  1478.         not generated.
  1479.         Suggested fix now in 1.33MR1.
  1480. #17.  (Version 1.33/3-Sep-96) Ron House  (house@helios.usq.edu.au)
  1481.         The routine ASTBase::predorder_action omits two "tree->"
  1482.         prefixes, which results in the preorder_action belonging
  1483.         to the wrong node to be invoked.
  1484.         Suggested fix now in 1.33MR1.
  1485. #16.  (Version 1.33/7-Jun-96)       Eli Sternheim <eli@interhdl.com>
  1486.         Routine consumeUntilToken() does not check for end-of-file
  1487.         condition.
  1488.         Suggested fix now in 1.33MR1.
  1489. #15.  (Version 1.33/8 Apr 96)   Asgeir Olafsson <olafsson@cstar.ac.com>
  1490.         Problem with tree duplication of doubly linked ASTs in ASTBase.cpp.
  1491.         Suggested fix now in 1.33MR1.
  1492. #14.  (Version 1.33/28-Feb-96)   Andreas.Magnusson@mailbox.swipnet.se
  1493.         Problem with definition of operator = (const ANTLRTokenPtr rhs).
  1494.         Suggested fix now in 1.33MR1.
  1495. #13.  (Version 1.33/13-Feb-96) Franklin Chen (chen@adi.com)
  1496.         Sun C++ Compiler 3.0.1 can't compile testcpp/1 due to goto in
  1497.         block with destructors.
  1498.         Apparently fixed. Can't locate "goto".
  1499. #12.  (Version 1.33/10-Nov-95)  Minor problems with 1.33 code
  1500.         The following items have been fixed in 1.33MR1:
  1501.           1.  pccts/antlr/main.c line 142
  1502.                 "void" appears in classic C code
  1503.           2.  no makefile in support/genmk
  1504.           3.  EXIT_FAILURE/_SUCCESS instead of PCCTS_EXIT_FAILURE/_SUCCESS
  1505.                 pccts/h/PCCTSAST.cpp
  1506.                 pccts/h/DLexerBase.cpp
  1507.                 pccts/testcpp/6/test.g
  1508.           4.  use of "signed int" isn't accepted by AT&T cfront
  1509.                 pccts/h/PCCTSAST.h line 42
  1510.           5.  in call to ANTLRParser::FAIL the var arg err_k is passed as
  1511.               "int" but is declared "unsigned int".
  1512.           6.  I believe that a failed validation predicate still does not
  1513.               get put in a "{...}" envelope, despite the release notes.
  1514.           7. The #token ">>" appearing in the DLG grammar description
  1515.              causes DLG to generate the string literal ">>" which
  1516.              is non-conforming and will cause some compilers to
  1517.              complain (scan.c function act10 line 143 of source code).
  1518. #11.  (Version 1.32b6)  Dave Kuhlman     (dkuhlman@netcom.com)
  1519.         Problem with file close in gen.c.  Already fixed in 1.33.
  1520. #10.  (Version 1.32b6/29-Aug-95)
  1521.         pccts/antlr/main.c contains a C++ style comments on lines 149
  1522.         and 176 which causes problems for most C compilers.
  1523.          Already fixed in 1.33.
  1524. #9.   (Version 1.32b4/14-Mar-95) dlgauto.h #include "config.h"
  1525.         The file pccts/h/dlgauto.h should probably contain a #include
  1526.         "config.h" as it uses the #define symbol __USE_PROTOS.
  1527.         Added to 1.33MR1.
  1528. #8.   (Version 1.32b4/6-Mar-95)  Michael T. Richter (mtr@igs.net)
  1529.         In C++ output mode anonymous tokens from in-line regular expressions
  1530.         can create enum values which are too wide for the datatype of the enum
  1531.         assigned by the C++ compiler.
  1532.         Fixed in 1.33MR1.
  1533. #7.   (Version 1.32b4/6-Mar-95)  C++ does not imply __STDC__
  1534.         In err.h the combination of # directives assumes that a C++
  1535.         compiler has __STDC__ defined.  This is not necessarily true.
  1536.         This problem also appears in the use of __USE_PROTOS which
  1537.         is appropriate for both Standard C and C++ in antlr/gen.c
  1538.         and antlr/lex.c
  1539.         Fixed in 1.33MR1.
  1540. #6.   (Version 1.32 ?/15-Feb-95) Name conflict for "TokenType"
  1541.         Already fixed in 1.33.
  1542. #5.   (23-Jan-95)        Douglas_Cuthbertson.JTIDS@jtids_qmail.hanscom.af.mil
  1543.         The fail action following a semantic predicate is not enclosed in
  1544.         "{...}". This can lead to problems when the fail action contains
  1545.         more than one statement.
  1546.         Fixed in 1.33MR1.
  1547. #4 .  (Version 1.33/31-Mar-96)   jlilley@empathy.com (John Lilley)
  1548.         Put briefly, a semantic predicate ought to abort a guess if it fails.
  1549.         Correction suggested by J. Lilley has been added to 1.33MR1.
  1550. #3 .  (Version 1.33)             P.A.Keller@bath.ac.uk
  1551.         Extra commas are placed in the K&R style argument list for rules
  1552.         when using both exceptions and ASTs.
  1553.         Fixed in 1.33MR1.
  1554. #2.   (Version 1.32b6/2-Oct-95)  Brad Schick <schick@interaccess.com>
  1555.         Construct #[] generates zzastnew() in C++ mode.
  1556.         Already fixed in 1.33.
  1557. #1.   (Version 1.33)     Bob Bailey (robert@oakhill.sps.mot.com)
  1558.         Previously, config.h assumed that all PC systems required
  1559.         "short" file names.  The user can now override that
  1560.         assumption with "#define LONGFILENAMES".
  1561.         Added to 1.33MR1.