changes_summary.txt
来自「EFI BIOS是Intel提出的下一代的BIOS标准。这里上传的Edk源代码是」· 文本 代码 · 共 1,594 行 · 第 1/5 页
TXT
1,594 行
choice unreachable. Consider the following example:
#pred A <<A(LATEXT(1)>>?
#pred B <<B(LATEXT(1)>>?
#pred A_or_B A || B
r : s
| t
;
s : <<A_or_B>>? ID
;
t : <<A>>? ID
;
----------------------------------------------------------------------------
t11.g, line 5: warning: the predicate used to disambiguate the
first choice of rule r
(file t11.g alt 1 line 5 and alt 2 line 6)
appears to "cover" the second predicate when compared without context.
The second predicate may have no resolving power for some lookahead
sequences.
----------------------------------------------------------------------------
#132. (Changed in 1.33MR11) Recognition of identical predicates in alts
Prior to 1.33MR11, there would be no ambiguity warning when the
very same predicate was used to disambiguate both alternatives:
test: ref B
| ref C
;
ref : <<pred(LATEXT(1)>>? A
In 1.33MR11 this will cause the warning:
warning: the predicates used to disambiguate rule test
(file v98.g alt 1 line 1 and alt 2 line 2)
are identical and have no resolving power
----------------- Note -----------------
This is different than the following case
test: <<pred(LATEXT(1))>>? A B
| <<pred(LATEXT(1)>>? A C
;
In this case there are two distinct predicates
which have exactly the same text. In the first
example there are two references to the same
predicate. The problem represented by this
grammar will be addressed later.
#127. (Changed in 1.33MR11)
Count Syntax Errors Count DLG Errors
------------------- ----------------
C++ mode ANTLRParser:: DLGLexerBase::
syntaxErrCount lexErrCount
C mode zzSyntaxErrCount zzLexErrCount
The C mode variables are global and initialized to 0.
They are *not* reset to 0 automatically when antlr is
restarted.
The C++ mode variables are public. They are initialized
to 0 by the constructors. They are *not* reset to 0 by the
ANTLRParser::init() method.
Suggested by Reinier van den Born (reinier@vnet.ibm.com).
#126. (Changed in 1.33MR11) Addition of #first <<...>>
The #first <<...>> inserts the specified text in the output
files before any other #include statements required by pccts.
The only things before the #first text are comments and
a #define ANTLR_VERSION.
Requested by and Esa Pulkkinen (esap@cs.tut.fi) and Alexin
Zoltan (alexin@inf.u-szeged.hu).
#124. A Note on the New "&&" Style Guarded Predicates
I've been asked several times, "What is the difference between
the old "=>" style guard predicates and the new style "&&" guard
predicates, and how do you choose one over the other" ?
The main difference is that the "=>" does not apply the
predicate if the context guard doesn't match, whereas
the && form always does. What is the significance ?
If you have a predicate which is not on the "leading edge"
it is cannot be hoisted. Suppose you need a predicate that
looks at LA(2). You must introduce it manually. The
classic example is:
castExpr :
LP typeName RP
| ....
;
typeName : <<isTypeName(LATEXT(1))>>? ID
| STRUCT ID
;
The problem is that isTypeName() isn't on the leading edge
of typeName, so it won't be hoisted into castExpr to help
make a decision on which production to choose.
The *first* attempt to fix it is this:
castExpr :
<<isTypeName(LATEXT(2))>>?
LP typeName RP
| ....
;
Unfortunately, this won't work because it ignores
the problem of STRUCT. The solution is to apply
isTypeName() in castExpr if LA(2) is an ID and
don't apply it when LA(2) is STRUCT:
castExpr :
(LP ID)? => <<isTypeName(LATEXT(2))>>?
LP typeName RP
| ....
;
In conclusion, the "=>" style guarded predicate is
useful when:
a. the tokens required for the predicate
are not on the leading edge
b. there are alternatives in the expression
selected by the predicate for which the
predicate is inappropriate
If (b) were false, then one could use a simple
predicate (assuming "-prc on"):
castExpr :
<<isTypeName(LATEXT(2))>>?
LP typeName RP
| ....
;
typeName : <<isTypeName(LATEXT(1))>>? ID
;
So, when do you use the "&&" style guarded predicate ?
The new-style "&&" predicate should always be used with
predicate context. The context guard is in ADDITION to
the automatically computed context. Thus it useful for
predicates which depend on the token type for reasons
other than context.
The following example is contributed by Reinier van den Born
(reinier@vnet.ibm.com).
+-------------------------------------------------------------------------+
| This grammar has two ways to call functions: |
| |
| - a "standard" call syntax with parens and comma separated args |
| - a shell command like syntax (no parens and spacing separated args) |
| |
| The former also allows a variable to hold the name of the function, |
| the latter can also be used to call external commands. |
| |
| The grammar (simplified) looks like this: |
| |
| fun_call : ID "(" { expr ("," expr)* } ")" |
| /* ID is function name */ |
| | "@" ID "(" { expr ("," expr)* } ")" |
| /* ID is var containing fun name */ |
| ; |
| |
| command : ID expr* /* ID is function name */ |
| | path expr* /* path is external command name */ |
| ; |
| |
| path : ID /* left out slashes and such */ |
| | "@" ID /* ID is environment var */ |
| ; |
| |
| expr : .... |
| | "(" expr ")"; |
| |
| call : fun_call |
| | command |
| ; |
| |
| Obviously the call is wildly ambiguous. This is more or less how this |
| is to be resolved: |
| |
| A call begins with an ID or an @ followed by an ID. |
| |
| If it is an ID and if it is an ext. command name -> command |
| if followed by a paren -> fun_call |
| otherwise -> command |
| |
| If it is an @ and if the ID is a var name -> fun_call |
| otherwise -> command |
| |
| One can implement these rules quite neatly using && predicates: |
| |
| call : ("@" ID)? && <<isVarName(LT(2))>>? fun_call |
| | (ID)? && <<isExtCmdName>>? command |
| | (ID "(")? fun_call |
| | command |
| ; |
| |
| This can be done better, so it is not an ideal example, but it |
| conveys the principle. |
+-------------------------------------------------------------------------+
#122. (Changed in 1.33MR11) Member functions to reset DLG in C++ mode
void DLGFileReset(FILE *f) { input = f; found_eof = 0; }
void DLGStringReset(DLGChar *s) { input = s; p = &input[0]; }
Supplied by R.A. Nelson (cowboy@VNET.IBM.COM)
#119. (Changed in 1.33MR11) Ambiguity aid for grammars
The user can ask for additional information on ambiguities reported
by antlr to stdout. At the moment, only one ambiguity report can
be created in an antlr run.
This feature is enabled using the "-aa" (Ambiguity Aid) option.
The following options control the reporting of ambiguities:
-aa ruleName Selects reporting by name of rule
-aa lineNumber Selects reporting by line number
(file name not compared)
-aam Selects "multiple" reporting for a token
in the intersection set of the
alternatives.
For instance, the token ID may appear dozens
of times in various paths as the program
explores the rules which are reachable from
the point of an ambiguity. With option -aam
every possible path the search program
encounters is reported.
Without -aam only the first encounter is
reported. This may result in incomplete
information, but the information may be
sufficient and much shorter.
-aad depth Selects the depth of the search.
The default value is 1.
The number of paths to be searched, and the
size of the report can grow geometrically
with the -ck value if a full search for all
contributions to the source of the ambiguity
is explored.
The depth represents the number of tokens
in the lookahead set which are matched against
the set of ambiguous tokens. A depth of 1
means that the search stops when a lookahead
sequence of just one token is matched.
A k=1 ck=6 grammar might generate 5,000 items
in a report if a full depth 6 search is made
with the Ambiguity Aid. The source of the
problem may be in the first token and obscured
by the volume of data - I hesitate to call
it information.
When the user selects a depth > 1, the search
is first performed at depth=1 for both
alternatives, then depth=2 for both alternatives,
etc.
Sample output for rule grammar in antlr.g itself:
+---------------------------------------------------------------------+
| Ambiguity Aid |
| |
| Choice 1: grammar/70 line 632 file a.g |
| Choice 2: grammar/82 line 644 file a.g |
| |
| Intersection of lookahead[1] sets: |
| |
| "\}" "class" "#errclass" "#tokclass" |
| |
| Choice:1 Depth:1 Group:1 ("#errclass") |
| 1 in (...)* block grammar/70 line 632 a.g |
| 2 to error grammar/73 line 635 a.g |
| 3 error error/1 line 894 a.g |
| 4 #token "#errclass" error/2 line 895 a.g |
| |
| Choice:1 Depth:1 Group:2 ("#tokclass") |
| 2 to tclass grammar/74 line 636 a.g |
| 3 tclass tclass/1 line 937 a.g |
| 4 #token "#tokclass" tclass/2 line 938 a.g |
| |
| Choice:1 Depth:1 Group:3 ("class") |
| 2 to class_def grammar/75 line 637 a.g |
| 3 class_def class_def/1 line 669 a.g |
| 4 #token "class" class_def/3 line 671 a.g |
| |
| Choice:1 Depth:1 Group:4 ("\}") |
| 2 #token "\}" grammar/76 line 638 a.g |
| |
| Choice:2 Depth:1 Group:5 ("#errclass") |
| 1 in (...)* block grammar/83 line 645 a.g |
| 2 to error grammar/93 line 655 a.g |
| 3 error error/1 line 894 a.g |
| 4 #token "#errclass" error/2 line 895 a.g |
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?