TianoCore / EDK II

------------------------------------------------------------ This is the second part of a two part file. This is a list of changes to pccts 1.33 prior to MR13 For more recent information see CHANGES_FROM_133.txt ------------------------------------------------------------ DISCLAIMER The software and these notes are provided "as is". They may include typographical or technical errors and their authors disclaims all liability of any kind or nature for damages due to error, fault, defect, or deficiency regardless of cause. All warranties of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. #153. (Changed in MR12b) Bug in computation of -mrhoist suppression set Consider the following grammar with k=1 and "-mrhoist on": r1 : (A)? => ((p>>? x /* l1 */ | r2 /* l2 */ ; r2 : A /* l4 */ | (B)? => <<q>>? y /* l5 */ ; In earlier versions the mrhoist routine would see that both l1 and l2 contained predicates and would assume that this prevented either from acting to suppress the other predicate. In the example above it didn't realize the A at line l4 is capable of suppressing the predicate at l1 even though alt l2 contains (indirectly) a predicate. This is fixed in MR12b. Reported by Reinier van den Born (reinier@vnet.ibm.com) #153. (Changed in MR12a) Bug in computation of -mrhoist suppression set An oversight similar to that described in Item #152 appeared in the computation of the set that "covered" a predicate. If a predicate expression included a term such as p=AND(q,r) the context of p was taken to be context(q) & context(r), when it should have been context(q) | context(r). This is fixed in MR12a. #152. (Changed in MR12) Bug in generation of predicate expressions The primary purpose for MR12 is to make quite clear that MR11 is obsolete and to fix the bug related to predicate expressions. In MR10 code was added to optimize the code generated for predicate expression tests. Unfortunately, there was a significant oversight in the code which resulted in a bug in the generation of code for predicate expression tests which contained predicates combined using AND: r0 : (r1)* "@" ; r1 : (AAA)? => <<p LATEXT(1)>>? r2 ; r2 : (BBB)? => <<q LATEXT(1)>>? Q | (BBB)? => <<r LATEXT(1)>>? Q ; In MR11 (and MR10 when using "-mrhoist on") the code generated for r0 to predict r1 would be equivalent to: if ( LA(1)==Q && (LA(1)==AAA && LA(1)==BBB) && ( p && ( q || r )) ) { This is incorrect because it expresses the idea that LA(1) *must* be AAA in order to attempt r1, and *must* be BBB to attempt r2. The result was that r1 became unreachable since both condition can not be simultaneously true. The general philosophy of code generation for predicates can be summarized as follows: a. If the context is true don't enter an alt for which the corresponding predicate is false. If the context is false then it is okay to enter the alt without evaluating the predicate at all. b. A predicate created by ORing of predicates has context which is the OR of their individual contexts. c. A predicate created by ANDing of predicates has (surprise) context which is the OR of their individual contexts. d. Apply these rules recursively. e. Remember rule (a) The correct code should express the idea that *if* LA(1) is AAA then p must be true to attempt r1, but if LA(1) is *not* AAA then it is okay to attempt r1, provided that *if* LA(1) is BBB then one of q or r must be true. if ( LA(1)==Q && ( !(LA(1)==AAA || LA(1)==BBB) || ( ! LA(1) == AAA || p) && ( ! LA(1) == BBB || q || r ) ) ) { I believe this is fixed in MR12. Reported by Reinier van den Born (reinier@vnet.ibm.com) #151a. (Changed in MR12) ANTLRParser::getLexer() As a result of several requests, I have added public methods to get a pointer to the lexer belonging to a parser. ANTLRTokenStream *ANTLRParser::getLexer() const Returns a pointer to the lexer being used by the parser. ANTLRTokenStream is the base class of DLGLexer ANTLRTokenStream *ANTLRTokenBuffer::getLexer() const Returns a pointer to the lexer being used by the ANTLRTokenBuffer. ANTLRTokenStream is the base class of DLGLexer You must manually cast the ANTLRTokenStream to your program's lexer class. Because the name of the lexer's class is not fixed. Thus it is impossible to incorporate it into the DLGLexerBase class. #151b.(Changed in MR12) ParserBlackBox member getLexer() The template class ParserBlackBox now has a member getLexer() which returns a pointer to the lexer. #150. (Changed in MR12) syntaxErrCount and lexErrCount now public See Item #127 for more information. #149. (Changed in MR12) antlr option -info o (letter o for orphan) If there is more than one rule which is not referenced by any other rule then all such rules are listed. This is useful for alerting one to rules which are not used, but which can still contribute to ambiguity. For example: start : a Z ; unused: a A ; a : (A)+ ; will cause an ambiguity report for rule "a" which will be difficult to understand if the user forgets about rule "unused" simply because it is not used in the grammar. #148. (Changed in MR11) #token names appearing in zztokens,token_tbl In a #token statement like the following: #token Plus "\+" the string "Plus" appears in the zztokens array (C mode) and token_tbl (C++ mode). This string is used in most error messages. In MR11 one has the option of using some other string, (e.g. "+") in those tables. In MR11 one can write: #token Plus ("+") "\+" #token RP ("(") "\(" #token COM ("comment begin") "/\*" A #token statement is allowed to appear in more than one #lexclass with different regular expressions. However, the token name appears only once in the zztokens/token_tbl array. This means that only one substitute can be specified for a given #token name. The second attempt to define a substitute name (different from the first) will result in an error message. #147. (Changed in MR11) Bug in follow set computation There is a bug in 1.33 vanilla and all maintenance releases prior to MR11 in the computation of the follow set. The bug is different than that described in Item #82 and probably more common. It was discovered in the ansi.g grammar while testing the "ambiguity aid" (Item #119). The search for a bug started when the ambiguity aid was unable to discover the actual source of an ambiguity reported by antlr. The problem appears when an optimization of the follow set computation is used inappropriately. The result is that the follow set used i