changes_from_133.txt

来自「EFI BIOS是Intel提出的下一代的BIOS标准。这里上传的Edk源代码是」· 文本 代码 · 共 1,767 行 · 第 1/5 页

      With 1.33MR14 the prediction expression is:

        ...
        if ( !zzrv && LA(1)==A && LA(2)==B) {
            alpha();
            zzGUESS_DONE
            beta();
            zzmatch(C);
            zzCONSUME;
        } else {
        ...

      This will only affect users in which alpha is shorter than
      than max(k,ck) and there is an action immediately preceding
      the syntactic predicate.

      This problem was reported by reported by Arpad Beszedes
      ([e-mail]) who provided a very clear example
      of the problem and identified the presence of the init-action
      as the likely culprit.

#173. (Changed in MR13a) -glms for Microsoft style filenames with -gl

      With the -gl option antlr generates #line directives using the
      exact name of the input files specified on the command line.
      An oddity of the Microsoft C and C++ compilers is that they
      don't accept file names in #line directives containing "\"
      even though these are names from the native file system.

      With -glms option, the "\" in file names appearing in #line
      directives is replaced with a "/" in order to conform to
      Microsoft compiler requirements.

      Reported by Erwin Achermann ([e-mail]).

#172. (Changed in MR13) \r\n in antlr source counted as one line

      Some MS software uses \r\n to indicate a new line.  Antlr
      now recognizes this in counting lines.

      Reported by Edward L. Hepler ([e-mail]).

#171. (Changed in MR13) #tokclass L..U now allowed

      The following is now allowed:

            #tokclass ABC { A..B C }

      Reported by Dave Watola ([e-mail])

#170. (Changed in MR13) Suppression for predicates with lookahead depth >1

      In MR12 the capability for suppression of predicates with lookahead
      depth=1 was introduced.  With MR13 this had been extended to
      predicates with lookahead depth > 1 and released for use by users
      on an experimental basis.

      Consider the following grammar with -ck 2 and the predicate in rule
      "a" with depth 2:

            r1  : (ab)* "@"
                ;

            ab  : a
                | b
                ;

            a   : (A B)? => <<p(LATEXT(2))>>? A B C
                ;

            b   : A B C
                ;

      Normally, the predicate would be hoisted into rule r1 in order to
      determine whether to call rule "ab".  However it should *not* be
      hoisted because, even if p is false, there is a valid alternative
      in rule b.  With "-mrhoistk on" the predicate will be suppressed.

      If "-info p" command line option is present the following information
      will appear in the generated code:

                while ( (LA(1)==A)
        #if 0

        Part (or all) of predicate with depth > 1 suppressed by alternative
            without predicate

        pred  <<  p(LATEXT(2))>>?
                  depth=k=2  ("=>" guard)  rule a  line 8  t1.g
          tree context:
            (root = A
               B
            )

        The token sequence which is suppressed: ( A B )
        The sequence of references which generate that sequence of tokens:

           1 to ab          r1/1       line 1     t1.g
           2 ab             ab/1       line 4     t1.g
           3 to b           ab/2       line 5     t1.g
           4 b              b/1        line 11    t1.g
           5 #token A       b/1        line 11    t1.g
           6 #token B       b/1        line 11    t1.g

        #endif

      A slightly more complicated example:

            r1  : (ab)* "@"
                ;

            ab  : a
                | b
                ;

            a   : (A B)? => <<p(LATEXT(2))>>? (A  B | D E)
                ;

            b   : <<q(LATEXT(2))>>? D E
                ;


      In this case, the sequence (D E) in rule "a" which lies behind
      the guard is used to suppress the predicate with context (D E)
      in rule b.

                while ( (LA(1)==A || LA(1)==D)
            #if 0

            Part (or all) of predicate with depth > 1 suppressed by alternative
                without predicate

            pred  <<  q(LATEXT(2))>>?
                              depth=k=2  rule b  line 11  t2.g
              tree context:
                (root = D
                   E
                )

            The token sequence which is suppressed: ( D E )
            The sequence of references which generate that sequence of tokens:

               1 to ab          r1/1       line 1     t2.g
               2 ab             ab/1       line 4     t2.g
               3 to a           ab/1       line 4     t2.g
               4 a              a/1        line 8     t2.g
               5 #token D       a/1        line 8     t2.g
               6 #token E       a/1        line 8     t2.g

            #endif
            &&
            #if 0

            pred  <<  p(LATEXT(2))>>?
                              depth=k=2  ("=>" guard)  rule a  line 8  t2.g
              tree context:
                (root = A
                   B
                )

            #endif

            (! ( LA(1)==A && LA(2)==B ) || p(LATEXT(2)) )  {
                ab();
                ...

#169. (Changed in MR13) Predicate test optimization for depth=1 predicates

      When the MR12 generated a test of a predicate which had depth 1
      it would use the depth >1 routines, resulting in correct but
      inefficient behavior.  In MR13, a bit test is used.

#168. (Changed in MR13) Token expressions in context guards

      The token expressions appearing in context guards such as:

            (A B)? => <<test(LT(1))>>?  someRule

      are computed during an early phase of antlr processing.  As
      a result, prior to MR13, complex expressions such as:

            ~B
            L..U
            ~L..U
            TokClassName
            ~TokClassName

      were not computed properly.  This resulted in incorrect
      context being computed for such expressions.

      In MR13 these context guards are verified for proper semantics
      in the initial phase and then re-evaluated after complex token
      expressions have been computed in order to produce the correct
      behavior.

      Reported by Arpad Beszedes ([e-mail]).

#167. (Changed in MR13) ~L..U

      Prior to MR13, the complement of a token range was
      not properly computed.

#166. (Changed in MR13) token expression L..U

      The token U was represented as an unsigned char, restricting
      the use of L..U to cases where U was assigned a token number
      less than 256.  This is corrected in MR13.

#165. (Changed in MR13) option -newAST

      To create ASTs from an ANTLRTokenPtr antlr usually calls
      "new AST(ANTLRTokenPtr)".  This option generates a call
      to "newAST(ANTLRTokenPtr)" instead.  This allows a user
      to define a parser member function to create an AST object.

      Similar changes for ASTBase::tmake and ASTBase::link were not
      thought necessary since they do not create AST objects, only
      use existing ones.

#164. (Changed in MR13) Unused variable _astp

      For many compilations, we have lived with warnings about
      the unused variable _astp.  It turns out that this varible
      can *never* be used because the code which references it was
      commented out.

      This investigation was sparked by a note from Erwin Achermann
      ([e-mail]).

#163. (Changed in MR13) Incorrect makefiles for testcpp examples

      All the examples in pccts/testcpp/* had incorrect definitions
      in the makefiles for the symbol "CCC".  Instead of CCC=CC they
      had CC=$(CCC).

      There was an additional problem in testcpp/1/test.g due to the
      change in ANTLRToken::getText() to a const member function
      (Item #137).

      Reported by Maurice Mass ([e-mail]).

#162. (Changed in MR13) Combining #token with #tokdefs

      When it became possible to change the print-name of a
      #token (Item #148) it became useful to give a #token
      statement whose only purpose was to giving a print name
      to the #token.  Prior to this change this could not be
      combined with the #tokdefs feature.

#161. (Changed in MR13) Switch -gxt inhibits generation of tokens.h

#160. (Changed in MR13) Omissions in list of names for remap.h

      When a user selects the -gp option antlr creates a list
      of macros in remap.h to rename some of the standard
      antlr routines from zzXXX to userprefixXXX.

      There were number of omissions from the remap.h name
      list related to the new trace facility.  This was reported,
      along with a fix, by Bernie Solomon ([e-mail]).

#159. (Changed in MR13) Violations of classic C rules

      There were a number of violations of classic C style in
      the distribution kit.  This was reported, along with fixes,
      by Bernie Solomon ([e-mail]).

#158. (Changed in MR13) #header causes problem for pre-processors

      A user who runs the C pre-processor on antlr source suggested
      that another syntax be allowed.  With MR13 such directives
      such as #header, #pragma, etc. may be written as "\#header",
      "\#pragma", etc.  For escaping pre-processor directives inside
      a #header use something like the following:

            \#header
            <<
                \#include <stdio.h>
            >>

#157. (Fixed in MR13) empty error sets for rules with infinite recursion

      When the first set for a rule cannot be computed due to infinite
      left recursion and it is the only alternative for a block then
      the error set for the block would be empty.  This would result
      in a fatal error.

      Reported by Darin Creason ([e-mail])

#156. (Changed in MR13) DLGLexerBase::getToken() now public

#155. (Changed in MR13) Context behind predicates can suppress

      With -mrhoist enabled the context behind a guarded predicate can
      be used to suppress other predicates.  Consider the following grammar:

        r0 : (r1)+;

        r1  : rp
            | rq
            ;
        rp  : <<p LATEXT(1)>>? B ;
        rq : (A)? => <<q LATEXT(1)>>? (A|B);

      In earlier versions both predicates "p" and "q" would be hoisted into
      rule r0. With MR12c predicate p is suppressed because the context which
      follows predicate q includes "B" which can "cover" predicate "p".  In
      other words, in trying to decide in r0 whether to call r1, it doesn't
      really matter whether p is false or true because, either way, there is
      a valid choice within r1.

#154. (Changed in MR13) Making hoist suppression explicit using <<nohoist>>

      A common error, even among experienced pccts users, is to code
      an init-action to inhibit hoisting rather than a leading action.
      An init-action does not inhibit hoisting.

      This was coded:

        rule1 : <<;>> rule2

      This is what was meant:

        rule1 : <<;>> <<;>> rule2

      With MR13, the user can code:

        rule1 : <<;>> <<nohoist>> rule2

      The following will give an error message:

        rule1 : <<nohoist>> rule2

      If the <<nohoist>> appears as an init-action rather than a leading
      action an error message is issued.  The meaning of an init-action
      containing "nohoist" is unclear: does it apply to just one
      alternative or to all alternatives ?








        -------------------------------------------------------
        Note:  Items #153 to #1 are now in a separate file named
                CHANGES_FROM_133_BEFORE_MR13.txt
        -------------------------------------------------------