changes_from_133.txt

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

    Reported by Greg Knapen ([e-mail]).

#195. (Changed in MR14) #line directive not at column 1

      Under certain circunstances a predicate test could generate
      a #line directive which was not at column 1.

      Reported with fix by David K錱edal  ([e-mail])
      (http://www.lysator.liu.se/~davidk/).

#194. (Changed in MR14) (C Mode only) Demand lookahead with #tokclass

      In C mode with the demand lookahead option there is a bug in the
      code which handles matches for #tokclass (zzsetmatch and
      zzsetmatch_wsig).

      The bug causes the lookahead pointer to get out of synchronization
      with the current token pointer.

      The problem was reported with a fix by Ger Hobbelt ([e-mail]).

#193. (Changed in MR14) Use of PCCTS_USE_NAMESPACE_STD

      The pcctscfg.h now contains the following definitions:

        #ifdef PCCTS_USE_NAMESPACE_STD
        #define PCCTS_STDIO_H     <Cstdio>
        #define PCCTS_STDLIB_H    <Cstdlib>
        #define PCCTS_STDARG_H    <Cstdarg>
        #define PCCTS_SETJMP_H    <Csetjmp>
        #define PCCTS_STRING_H    <Cstring>
        #define PCCTS_ASSERT_H    <Cassert>
        #define PCCTS_ISTREAM_H   <istream>
        #define PCCTS_IOSTREAM_H  <iostream>
        #define PCCTS_NAMESPACE_STD     namespace std {}; using namespace std;
        #else
        #define PCCTS_STDIO_H     <stdio.h>
        #define PCCTS_STDLIB_H    <stdlib.h>
        #define PCCTS_STDARG_H    <stdarg.h>
        #define PCCTS_SETJMP_H    <setjmp.h>
        #define PCCTS_STRING_H    <string.h>
        #define PCCTS_ASSERT_H    <assert.h>
        #define PCCTS_ISTREAM_H   <istream.h>
        #define PCCTS_IOSTREAM_H  <iostream.h>
        #define PCCTS_NAMESPACE_STD
        #endif

      The runtime support in pccts/h uses these pre-processor symbols
      consistently.

      Also, antlr and dlg have been changed to generate code which uses
      these pre-processor symbols rather than having the names of the
      #include files hard-coded in the generated code.

      This required the addition of "#include pcctscfg.h" to a number of
      files in pccts/h.

      It appears that this sometimes causes problems for MSVC 5 in
      combination with the "automatic" option for pre-compiled headers.
      In such cases disable the "automatic" pre-compiled headers option.

      Suggested by Hubert Holin ([e-mail]).

#192. (Changed in MR14) Change setText() to accept "const ANTLRChar *"

      Changed ANTLRToken::setText(ANTLRChar *) to setText(const ANTLRChar *).
      This allows literal strings to be used to initialize tokens.  Since
      the usual token implementation (ANTLRCommonToken)  makes a copy of the
      input string, this was an unnecessary limitation.

      Suggested by Bob McWhirter ([e-mail]).

#191. (Changed in MR14) HP/UX aCC compiler compatibility problem

      Needed to explicitly declare zzINF_DEF_TOKEN_BUFFER_SIZE and
      zzINF_BUFFER_TOKEN_CHUNK_SIZE as ints in pccts/h/AParser.cpp.

      Reported by David Cook ([e-mail]).

#190. (Changed in MR14) IBM OS/2 CSet compiler compatibility problem

      Name conflict with "_cs" in pccts/h/ATokenBuffer.cpp

      Reported by David Cook ([e-mail]).

#189. (Changed in MR14) -gxt switch in C mode

      The -gxt switch in C mode didn't work because of incorrect
      initialization.

      Reported by Sinan Karasu ([e-mail]).

#188. (Changed in MR14) Added pccts/h/DLG_stream_input.h

      This is a DLG stream class based on C++ istreams.

      Contributed by Hubert Holin ([e-mail]).

#187. (Changed in MR14) Rename config.h to pcctscfg.h

      The PCCTS configuration file has been renamed from config.h to
      pcctscfg.h.  The problem with the original name is that it led
      to name collisions when pccts parsers were combined with other
      software.

      All of the runtime support routines in pccts/h/* have been
      changed to use the new name.  Existing software can continue
      to use pccts/h/config.h. The contents of pccts/h/config.h is
      now just "#include "pcctscfg.h".

      I don't have a record of the user who suggested this.

#186. (Changed in MR14) Pre-processor symbol DllExportPCCTS class modifier

      Classes in the C++ runtime support routines are now declared:

        class DllExportPCCTS className ....

      By default, the pre-processor symbol is defined as the empty
      string.  This if for use by MSVC++ users to create DLL classes.

      Suggested by Manfred Kogler ([e-mail]).

#185. (Changed in MR14) Option to not use PCCTS_AST base class for ASTBase

      Normally, the ASTBase class is derived from PCCTS_AST which contains
      functions useful to Sorcerer.  If these are not necessary then the
      user can define the pre-processor symbol "PCCTS_NOT_USING_SOR" which
      will cause the ASTBase class to replace references to PCCTS_AST with
      references to ASTBase where necessary.

      The class ASTDoublyLinkedBase will contain a pure virtual function
      shallowCopy() that was formerly defined in class PCCTS_AST.

      Suggested by Bob McWhirter ([e-mail]).

#184. (Changed in MR14) Grammars with no tokens generate invalid tokens.h

      Reported by Hubert Holin ([e-mail]).

#183. (Changed in MR14) -f to specify file with names of grammar files

      In DEC/VMS it is difficult to specify very long command lines.
      The -f option allows one to place the names of the grammar files
      in a data file in order to bypass limitations of the DEC/VMS
      command language interpreter.

      Addition supplied by Bernard Giroud ([e-mail]).

#182. (Changed in MR14) Output directory option for DEC/VMS

      Fix some problems with the -o option under DEC/VMS.

      Fix supplied by Bernard Giroud ([e-mail]).

#181. (Changed in MR14) Allow chars > 127 in DLGStringInput::nextChar()

      Changed DLGStringInput to cast the character using (unsigned char)
      so that languages with character codes greater than 127 work
      without changes.

      Suggested by Manfred Kogler ([e-mail]).

#180. (Added in MR14) ANTLRParser::getEofToken()

      Added "ANTLRToken ANTLRParser::getEofToken() const" to match the
      setEofToken routine.

      Requested by Manfred Kogler ([e-mail]).

#179. (Fixed in MR14) Memory leak for BufFileInput subclass of DLGInputStream

      The BufFileInput class described in Item #142 neglected to release
      the allocated buffer when an instance was destroyed.

      Reported by Manfred Kogler ([e-mail]).

#178. (Fixed in MR14) Bug in "(alpha)? beta" guess blocks first sets

      In 1.33 vanilla, and all maintenance releases prior to MR14
      there is a bug in the handling of guess blocks which use the
      "long" form:

                  (alpha)? beta

      inside a (...)*, (...)+, or {...} block.

      This problem does *not* apply to the case where beta is omitted
      or when the syntactic predicate is on the leading edge of an
      alternative.

      The problem is that both alpha and beta are stored in the
      syntax diagram, and that some analysis routines would fail
      to skip the alpha portion when it was not on the leading edge.
      Consider the following grammar with -ck 2:

                r : ( (A)? B )* C D

                  | A B      /* forces -ck 2 computation for old antlr    */
                             /*              reports ambig for alts 1 & 2 */

                  | B C      /* forces -ck 2 computation for new antlr    */
                             /*              reports ambig for alts 1 & 3 */
                  ;

      The prediction expression for the first alternative should be
      LA(1)={B C} LA(2)={B C D}, but previous versions of antlr
      would compute the prediction expression as LA(1)={A C} LA(2)={B D}

      Reported by Arpad Beszedes ([e-mail]) who provided
      a very clear example of the problem and identified the probable cause.

#177. (Changed in MR14) #tokdefs and #token with regular expression

      In MR13 the change described by Item #162 caused an existing
      feature of antlr to fail.  Prior to the change it was possible
      to give regular expression definitions and actions to tokens
      which were defined via the #tokdefs directive.

      This now works again.

      Reported by Manfred Kogler ([e-mail]).

#176. (Changed in MR14) Support for #line in antlr source code

      Note: this was implemented by Arpad Beszedes ([e-mail]).

      In 1.33MR14 it is possible for a pre-processor to generate #line
      directives in the antlr source and have those line numbers and file
      names used in antlr error messages and in the #line directives
      generated by antlr.

      The #line directive may appear in the following forms:

            #line ll "sss" xx xx ...

      where ll represents a line number, "sss" represents the name of a file
      enclosed in quotation marks, and xxx are arbitrary integers.

      The following form (without "line") is not supported at the moment:

            # ll "sss" xx xx ...

      The result:

        zzline

            is replaced with ll from the # or #line directive

        FileStr[CurFile]

            is updated with the contents of the string (if any)
            following the line number

      Note
      ----
      The file-name string following the line number can be a complete
      name with a directory-path. Antlr generates the output files from
      the input file name (by replacing the extension from the file-name
      with .c or .cpp).

      If the input file (or the file-name from the line-info) contains
      a path:

        "../grammar.g"

      the generated source code will be placed in "../grammar.cpp" (i.e.
      in the parent directory).  This is inconvenient in some cases
      (even the -o switch can not be used) so the path information is
      removed from the #line directive.  Thus, if the line-info was

        #line 2 "../grammar.g"

      then the current file-name will become "grammar.g"

      In this way, the generated source code according to the grammar file
      will always be in the current directory, except when the -o switch
      is used.

#175. (Changed in MR14) Bug when guess block appears at start of (...)*

      In 1.33 vanilla and all maintenance releases prior to 1.33MR14
      there is a bug when a guess block appears at the start of a (...)+.
      Consider the following k=1 (ck=1) grammar:

            rule :
                  ( (STAR)? ZIP )* ID ;

      Prior to 1.33MR14, the generated code resembled:

        ...
        zzGUESS_BLOCK
        while ( 1 ) {
            if ( ! LA(1)==STAR) break;
            zzGUESS
            if ( !zzrv ) {
                zzmatch(STAR);
                zzCONSUME;
                zzGUESS_DONE
                zzmatch(ZIP);
                zzCONSUME;
            ...

      Note that the routine uses STAR for the prediction expression
      rather than ZIP.  With 1.33MR14 the generated code resembles:

        ...
        while ( 1 ) {
            if ( ! LA(1)==ZIP) break;
        ...

      This problem existed only with (...)* blocks and was caused
      by the slightly more complicate graph which represents (...)*
      blocks.  This caused the analysis routine to compute the first
      set for the alpha part of the "(alpha)? beta" rather than the
      beta part.

      Both (...)+ and {...} blocks handled the guess block correctly.

      Reported by Arpad Beszedes ([e-mail]) who provided
      a very clear example of the problem and identified the probable cause.

#174. (Changed in MR14) Bug when action precedes syntactic predicate

      In 1.33 vanilla, and all maintenance releases prior to MR14,
      there was a bug when a syntactic predicate was immediately
      preceded by an action.  Consider the following -ck 2 grammar:

            rule :
                   <<int i;>>
                   (alpha)? beta C
                 | A B
                 ;

            alpha : A ;
            beta  : A B;

      Prior to MR14, the code generated for the first alternative
      resembled:

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

      The prediction expression (i.e. LA(1)==A && LA(2)==A) is clearly
      wrong because LA(2) should be matched to B (first[2] of beta is {B}).