changes_from_133.txt

来自「SRI international 发布的OAA框架软件」· 文本 代码 · 共 1,744 行 · 第 1/5 页

    Suggested by David Venditti (07751870267-0001 t-online.de).

#214. (Changed in MR19)  C mode: Adjust AST stack pointer at exit

    In C mode the AST stack pointer needs to be reset if there will
    be multiple calls to the ANTLRx macros.

    Reported with fix by Paul D. Smith (psmith baynetworks.com).

#213. (Changed in MR18)  Fatal error with -mrhoistk (k>1 hoisting)

    When rearranging code I forgot to un-comment a critical line of
    code that handles hoisting of predicates with k>1 lookahead.  This
    is now fixed.

    Reported by Reinier van den Born (reinier vnet.ibm.com).

#212. (Changed in MR17)  Mac related changes by Kenji Tanaka

    Kenji Tanaka (kentar osa.att.ne.jp) has made a number of changes for
    Macintosh users.

    a.  The following Macintosh MPW files aid in installing pccts on Mac:

            pccts/MPW_Read_Me

            pccts/install68K.mpw
            pccts/installPPC.mpw

            pccts/antlr/antlr.r
            pccts/antlr/antlr68K.make
            pccts/antlr/antlrPPC.make

            pccts/dlg/dlg.r
            pccts/dlg/dlg68K.make
            pccts/dlg/dlgPPC.make

            pccts/sorcerer/sor.r
            pccts/sorcerer/sor68K.make
            pccts/sorcerer/sorPPC.make
    
       They completely replace the previous Mac installation files.
            
    b. The most significant is a change in the MAC_FILE_CREATOR symbol
       in pcctscfg.h:

        old: #define MAC_FILE_CREATOR 'MMCC'   /* Metrowerks C/C++ Text files */
        new: #define MAC_FILE_CREATOR 'CWIE'   /* Metrowerks C/C++ Text files */

    c.  Added calls to special_fopen_actions() where necessary.

#211. (Changed in MR16a)  C++ style comment in dlg

    This has been fixed.

#210. (Changed in MR16a)  Sor accepts \r\n, \r, or \n for end-of-line

    A user requested that Sorcerer be changed to accept other forms
    of end-of-line.

#209. (Changed in MR16) Name of files changed.

        Old:  CHANGES_FROM_1.33
        New:  CHANGES_FROM_133.txt

        Old:  KNOWN_PROBLEMS
        New:  KNOWN_PROBLEMS.txt

#208. (Changed in MR16) Change in use of pccts #include files

    There were problems with MS DevStudio when mixing Sorcerer and
    PCCTS in the same source file.  The problem is caused by the
    redefinition of setjmp in the MS header file setjmp.h.  In
    setjmp.h the pre-processor symbol setjmp was redefined to be
    _setjmp.  A later effort to execute #include <setjmp.h> resulted 
    in an effort to #include <_setjmp.h>.  I'm not sure whether this
    is a bug or a feature.  In any case, I decided to fix it by
    avoiding the use of pre-processor symbols in #include statements
    altogether.  This has the added benefit of making pre-compiled
    headers work again.

    I've replaced statements:

        old: #include PCCTS_SETJMP_H
        new: #include "pccts_setjmp.h"

    Where pccts_setjmp.h contains:

            #ifndef __PCCTS_SETJMP_H__
            #define __PCCTS_SETJMP_H__
    
            #ifdef PCCTS_USE_NAMESPACE_STD
            #include <Csetjmp>
            #else
            #include <setjmp.h>
            #endif

            #endif
        
    A similar change has been made for other standard header files
    required by pccts and sorcerer: stdlib.h, stdarg.h, stdio.h, etc.

    Reported by Jeff Vincent (JVincent novell.com) and Dale Davis
    (DalDavis spectrace.com).

#207. (Changed in MR16) dlg reports an invalid range for: [\0x00-\0xff]

     -----------------------------------------------------------------
     Note from MR23:  This fix does not work.  I am investigating why.
     -----------------------------------------------------------------

    dlg will report that this is an invalid range.

    Diagnosed by Piotr Eljasiak (eljasiak no-spam.zt.gdansk.tpsa.pl):

        I think this problem is not specific to unsigned chars
        because dlg reports no error for the range [\0x00-\0xfe].

        I've found that information on range is kept in field
        letter (unsigned char) of Attrib struct. Unfortunately
        the letter value internally is for some reasons increased
        by 1, so \0xff is represented here as 0.

        That's why dlg complains about the range [\0x00-\0xff] in
        dlg_p.g:

        if ($$.letter > $2.letter) {
          error("invalid range  ", zzline);
        } 

    The fix is:

        if ($$.letter > $2.letter && 255 != $$2.letter) {
          error("invalid range  ", zzline);
        } 

#206. (Changed in MR16) Free zzFAILtext in ANTLRParser destructor

    The ANTLRParser destructor now frees zzFAILtext.

    Problem and fix reported by Manfred Kogler (km cast.uni-linz.ac.at).

#205. (Changed in MR16) DLGStringReset argument now const

    Changed: void DLGStringReset(DLGChar *s) {...}
    To:      void DLGStringReset(const DLGChar *s) {...}

    Suggested by Dale Davis (daldavis spectrace.com)

#204. (Changed in MR15a) Change __WATCOM__ to __WATCOMC__ in pcctscfg.h
    
    Reported by Oleg Dashevskii (olegdash my-dejanews.com).

#203. (Changed in MR15) Addition of sorcerer to distribution kit

    I have finally caved in to popular demand.  The pccts 1.33mr15
    kit will include sorcerer.  The separate sorcerer kit will be
    discontinued.

#202. (Changed) in MR15) Organization of MS Dev Studio Projects in Kit

    Previously there was one workspace that contained projects for
    all three parts of pccts: antlr, dlg, and sorcerer.  Now each
    part (and directory) has its own workspace/project and there
    is an additional workspace/project to build a library from the
    .cpp files in the pccts/h directory.

    The library build will create pccts_debug.lib or pccts_release.lib
    according to the configuration selected.  

    If you don't want to build pccts 1.33MR15 you can download a
    ready-to-run kit for win32 from http://www.polhode.com/win32.zip.
    The ready-to-run for win32 includes executables, a pre-built static
    library for the .cpp files in the pccts/h directory, and a  sample
    application

    You will need to define the environment variable PCCTS to point to
    the root of the pccts directory hierarchy.

#201. (Changed in MR15) Several fixes by K.J. Cummings (cummings peritus.com)

      Generation of SETJMP rather than SETJMP_H in gen.c.

      (Sor B19) Declaration of ref_vars_inits for ref_var_inits in
      pccts/sorcerer/sorcerer.h.

#200. (Changed in MR15) Remove operator=() in AToken.h

      User reported that WatCom couldn't handle use of
      explicit operator =().  Replace with equivalent
      using cast operator.

#199. (Changed in MR15) Don't allow use of empty #tokclass

      Change antlr.g to disallow empty #tokclass sets.

      Reported by Manfred Kogler (km cast.uni-linz.ac.at).

#198. Revised ANSI C grammar due to efforts by Manuel Kessler

      Manuel Kessler (mlkessler cip.physik.uni-wuerzburg.de)

          Allow trailing ... in function parameter lists.
          Add bit fields.
          Allow old-style function declarations.
          Support cv-qualified pointers.
          Better checking of combinations of type specifiers.
          Release of memory for local symbols on scope exit.
          Allow input file name on command line as well as by redirection.

              and other miscellaneous tweaks.

      This is not part of the pccts distribution kit. It must be
      downloaded separately from:

            http://www.polhode.com/ansi_mr15.zip

#197. (Changed in MR14) Resetting the lookahead buffer of the parser

      Explanation and fix by Sinan Karasu (sinan.karasu boeing.com)

      Consider the code used to prime the lookahead buffer LA(i)
      of the parser when init() is called:

        void
        ANTLRParser::
        prime_lookahead()
        {
            int i;
            for(i=1;i<=LLk; i++) consume();
            dirty=0;
            //lap = 0;      // MR14 - Sinan Karasu (sinan.karusu boeing.com)
            //labase = 0;   // MR14
            labase=lap;     // MR14
        }

      When the parser is instantiated, lap=0,labase=0 is set.

      The "for" loop runs LLk times. In consume(), lap = lap +1 (mod LLk) is
      computed.  Therefore, lap(before the loop) == lap (after the loop).

      Now the only problem comes in when one does an init() of the parser
      after an Eof has been seen. At that time, lap could be non zero.
      Assume it was lap==1. Now we do a prime_lookahead(). If LLk is 2,
      then

        consume()
        {
            NLA = inputTokens->getToken()->getType();
            dirty--;
            lap = (lap+1)&(LLk-1);
        }

      or expanding NLA,

        token_type[lap&(LLk-1)]) = inputTokens->getToken()->getType();
        dirty--;
        lap = (lap+1)&(LLk-1);

      so now we prime locations 1 and 2.  In prime_lookahead it used to set
      lap=0 and labase=0.  Now, the next token will be read from location 0,
      NOT 1 as it should have been.

      This was never caught before, because if a parser is just instantiated,
      then lap and labase are 0, the offending assignment lines are
      basically no-ops, since the for loop wraps around back to 0.

#196. (Changed in MR14) Problems with "(alpha)? beta" guess

    Consider the following syntactic predicate in a grammar
    with 2 tokens of lookahead (k=2 or ck=2):

        rule  : ( alpha )? beta ;
        alpha : S t ;
        t     : T U
              | T
              ;
        beta  : S t Z ;

    When antlr computes the prediction expression with one token
    of lookahead for alts 1 and 2 of rule t it finds an ambiguity.

    Because the grammar has a lookahead of 2 it tries to compute
    two tokens of lookahead for alts 1 and 2 of t.  Alt 1 clearly
    has a lookahead of (T U).  Alt 2 is one token long so antlr
    tries to compute the follow set of alt 2, which means finding
    the things which can follow rule t in the context of (alpha)?.
    This cannot be computed, because alpha is only part of a rule,
    and antlr can't tell what part of beta is matched by alpha and
    what part remains to be matched.  Thus it impossible for antlr
    to  properly determine the follow set of rule t.

    Prior to 1.33MR14, the follow of (alpha)? was computed as
    FIRST(beta) as a result of the internal representation of
    guess blocks.

    With MR14 the follow set will be the empty set for that context.

    Normally, one expects a rule appearing in a guess block to also
    appear elsewhere.  When the follow context for this other use
    is "ored" with the empty set, the context from the other use
    results, and a reasonable follow context results.  However if
    there is *no* other use of the rule, or it is used in a different
    manner then the follow context will be inaccurate - it was
    inaccurate even before MR14, but it will be inaccurate in a
    different way.

    For the example given earlier, a reasonable way to rewrite the
    grammar:

        rule  : ( alpha )? beta
        alpha : S t ;
        t     : T U
              | T
              ;
        beta  : alpha Z ;

    If there are no other uses of the rule appearing in the guess
    block it will generate a test for EOF - a workaround for
    representing a null set in the lookahead tests.

    If you encounter such a problem you can use the -alpha option
    to get additional information:

    line 2: error: not possible to compute follow set for alpha
              in an "(alpha)? beta" block.

    With the antlr -alpha command line option the following information
    is inserted into the generated file:

    #if 0

      Trace of references leading to attempt to compute the follow set of
      alpha in an "(alpha)? beta" block. It is not possible for antlr to
      compute this follow set because it is not known what part of beta has
      already been matched by alpha and what part remains to be matched.

      Rules which make use of the incorrect follow set will also be incorrect

         1 #token T              alpha/2   line 7     brief.g
         2 end alpha             alpha/3   line 8     brief.g
         2 end (...)? block at   start/1   line 2     brief.g

    #endif

    At the moment, with the -alpha option selected the program marks
    any rules which appear in the trace back chain (above) as rules with