📄 java.g
字号:
// allow ClassName[].class
| ( lbc:LBRACK^ {#lbc.setType(ARRAY_DECLARATOR);} RBRACK! )+
DOT^ "class"
// an array indexing operation
| lb:LBRACK^ {#lb.setType(INDEX_OP);} expression RBRACK!
// method invocation
// The next line is not strictly proper; it allows x(3)(4) or
// x[2](4) which are not valid in Java. If this grammar were used
// to validate a Java program a semantic check would be needed, or
// this rule would get really ugly...
// It also allows ctor invocation like super(3) which is now
// handled by the explicit constructor rule, but it would
// be hard to syntactically prevent ctor calls here
| lp:LPAREN^ {#lp.setType(METHOD_CALL);}
argList
RPAREN!
)*
// possibly add on a post-increment or post-decrement.
// allows INC/DEC on too much, but semantics can check
( in:INC^ {#in.setType(POST_INC);}
| de:DEC^ {#de.setType(POST_DEC);}
| // nothing
)
;
// the basic element of an expression
primaryExpression
: IDENT
| constant
| "true"
| "false"
| "this"
| "null"
| newExpression
| LPAREN! assignmentExpression RPAREN!
| "super"
// look for int.class and int[].class
| builtInType
( lbt:LBRACK^ {#lbt.setType(ARRAY_DECLARATOR);} RBRACK! )*
DOT^ "class"
;
/** object instantiation.
* Trees are built as illustrated by the following input/tree pairs:
*
* new T()
*
* new
* |
* T -- ELIST
* |
* arg1 -- arg2 -- .. -- argn
*
* new int[]
*
* new
* |
* int -- ARRAY_DECLARATOR
*
* new int[] {1,2}
*
* new
* |
* int -- ARRAY_DECLARATOR -- ARRAY_INIT
* |
* EXPR -- EXPR
* | |
* 1 2
*
* new int[3]
* new
* |
* int -- ARRAY_DECLARATOR
* |
* EXPR
* |
* 3
*
* new int[1][2]
*
* new
* |
* int -- ARRAY_DECLARATOR
* |
* ARRAY_DECLARATOR -- EXPR
* | |
* EXPR 1
* |
* 2
*
*/
newExpression
: "new"^ type
( LPAREN! argList RPAREN! (classBlock)?
//java 1.1
// Note: This will allow bad constructs like
// new int[4][][3] {exp,exp}.
// There needs to be a semantic check here...
// to make sure:
// a) [ expr ] and [ ] are not mixed
// b) [ expr ] and an init are not used together
| newArrayDeclarator (arrayInitializer)?
)
;
argList
: ( expressionList
| /*nothing*/
{#argList = #[ELIST,"ELIST"];}
)
;
newArrayDeclarator
: (
// CONFLICT:
// newExpression is a primaryExpression which can be
// followed by an array index reference. This is ok,
// as the generated code will stay in this loop as
// long as it sees an LBRACK (proper behavior)
options {
warnWhenFollowAmbig = false;
}
:
lb:LBRACK^ {#lb.setType(ARRAY_DECLARATOR);}
(expression)?
RBRACK!
)+
;
constant
: NUM_INT
| CHAR_LITERAL
| STRING_LITERAL
| NUM_FLOAT
| NUM_LONG
| NUM_DOUBLE
;
/** Java 1.3 Lexer.
*
* This grammar is in the PUBLIC DOMAIN
*
* @author John Mitchell johnm@non.net
* @author Terence Parr parrt@magelang.com
* @author John Lilley jlilley@empathy.com
* @author Scott Stanchfield thetick@magelang.com
* @author Markus Mohnen mohnen@informatik.rwth-aachen.de
* @author Peter Williams pete.williams@sun.com
* @author Allan Jacobs Allan.Jacobs@eng.sun.com
* @author Steve Messick messick@redhills.com
*
*/
class JavaLexer extends Lexer;
options {
exportVocab=Java; // call the vocabulary "Java"
testLiterals=false; // don't automatically test for literals
k=4; // four characters of lookahead
charVocabulary='\u0003'..'\uFFFF';
// without inlining some bitset tests, couldn't do unicode;
// I need to make ANTLR generate smaller bitsets; see
// bottom of JavaLexer.java
codeGenBitsetTestThreshold=20;
}
// OPERATORS
QUESTION : '?' ;
LPAREN : '(' ;
RPAREN : ')' ;
LBRACK : '[' ;
RBRACK : ']' ;
LCURLY : '{' ;
RCURLY : '}' ;
COLON : ':' ;
COMMA : ',' ;
//DOT : '.' ;
ASSIGN : '=' ;
EQUAL : "==" ;
LNOT : '!' ;
BNOT : '~' ;
NOT_EQUAL : "!=" ;
DIV : '/' ;
DIV_ASSIGN : "/=" ;
PLUS : '+' ;
PLUS_ASSIGN : "+=" ;
INC : "++" ;
MINUS : '-' ;
MINUS_ASSIGN : "-=" ;
DEC : "--" ;
STAR : '*' ;
STAR_ASSIGN : "*=" ;
MOD : '%' ;
MOD_ASSIGN : "%=" ;
SR : ">>" ;
SR_ASSIGN : ">>=" ;
BSR : ">>>" ;
BSR_ASSIGN : ">>>=" ;
GE : ">=" ;
GT : ">" ;
SL : "<<" ;
SL_ASSIGN : "<<=" ;
LE : "<=" ;
LT : '<' ;
BXOR : '^' ;
BXOR_ASSIGN : "^=" ;
BOR : '|' ;
BOR_ASSIGN : "|=" ;
LOR : "||" ;
BAND : '&' ;
BAND_ASSIGN : "&=" ;
LAND : "&&" ;
SEMI : ';' ;
// Whitespace -- ignored
WS : ( ' '
| '\t'
| '\f'
// handle newlines
| ( options {generateAmbigWarnings=false;}
: "\r\n" // Evil DOS
| '\r' // Macintosh
| '\n' // Unix (the right way)
)
{ newline(); }
)+
{ _ttype = Token.SKIP; }
;
// Single-line comments
SL_COMMENT
: "//"
(~('\n'|'\r'))* ('\n'|'\r'('\n')?)
{$setType(Token.SKIP); newline();}
;
// multiple-line comments
ML_COMMENT
: "/*"
( /* '\r' '\n' can be matched in one alternative or by matching
'\r' in one iteration and '\n' in another. I am trying to
handle any flavor of newline that comes in, but the language
that allows both "\r\n" and "\r" and "\n" to all be valid
newline is ambiguous. Consequently, the resulting grammar
must be ambiguous. I'm shutting this warning off.
*/
options {
generateAmbigWarnings=false;
}
:
{ LA(2)!='/' }? '*'
| '\r' '\n' {newline();}
| '\r' {newline();}
| '\n' {newline();}
| ~('*'|'\n'|'\r')
)*
"*/"
{$setType(Token.SKIP);}
;
// character literals
CHAR_LITERAL
: '\'' ( ESC | ~'\'' ) '\''
;
// string literals
STRING_LITERAL
: '"' (ESC|~('"'|'\\'))* '"'
;
// escape sequence -- note that this is protected; it can only be called
// from another lexer rule -- it will not ever directly return a token to
// the parser
// There are various ambiguities hushed in this rule. The optional
// '0'...'9' digit matches should be matched here rather than letting
// them go back to STRING_LITERAL to be matched. ANTLR does the
// right thing by matching immediately; hence, it's ok to shut off
// the FOLLOW ambig warnings.
protected
ESC
: '\\'
( 'n'
| 'r'
| 't'
| 'b'
| 'f'
| '"'
| '\''
| '\\'
| ('u')+ HEX_DIGIT HEX_DIGIT HEX_DIGIT HEX_DIGIT
| ('0'..'3')
(
options {
warnWhenFollowAmbig = false;
}
: ('0'..'7')
(
options {
warnWhenFollowAmbig = false;
}
: '0'..'7'
)?
)?
| ('4'..'7')
(
options {
warnWhenFollowAmbig = false;
}
: ('0'..'9')
)?
)
;
// hexadecimal digit (again, note it's protected!)
protected
HEX_DIGIT
: ('0'..'9'|'A'..'F'|'a'..'f')
;
// a dummy rule to force vocabulary to be all characters (except special
// ones that ANTLR uses internally (0 to 2)
protected
VOCAB
: '\3'..'\377'
;
// an identifier. Note that testLiterals is set to true! This means
// that after we match the rule, we look in the literals table to see
// if it's a literal or really an identifer
IDENT
options {testLiterals=true;}
: ('a'..'z'|'A'..'Z'|'_'|'$') ('a'..'z'|'A'..'Z'|'_'|'0'..'9'|'$')*
;
// a numeric literal
NUM_INT
{boolean isDecimal=false; Token t=null;}
: '.' {_ttype = DOT;}
( ('0'..'9')+ (EXPONENT)? (f1:FLOAT_SUFFIX {t=f1;})?
{
if (t != null && t.getText().toUpperCase().indexOf('D')>=0) {
_ttype = NUM_DOUBLE;
}
else {
_ttype = NUM_FLOAT;
}
}
)?
| ( '0' {isDecimal = true;} // special case for just '0'
( ('x'|'X')
( // hex
// the 'e'|'E' and float suffix stuff look
// like hex digits, hence the (...)+ doesn't
// know when to stop: ambig. ANTLR resolves
// it correctly by matching immediately. It
// is therefor ok to hush warning.
options {
warnWhenFollowAmbig=false;
}
: HEX_DIGIT
)+
| ('0'..'7')+ // octal
)?
| ('1'..'9') ('0'..'9')* {isDecimal=true;} // non-zero decimal
)
( ('l'|'L') { _ttype = NUM_LONG; }
// only check to see if it's a float if looks like decimal so far
| {isDecimal}?
( '.' ('0'..'9')* (EXPONENT)? (f2:FLOAT_SUFFIX {t=f2;})?
| EXPONENT (f3:FLOAT_SUFFIX {t=f3;})?
| f4:FLOAT_SUFFIX {t=f4;}
)
{
if (t != null && t.getText().toUpperCase() .indexOf('D') >= 0) {
_ttype = NUM_DOUBLE;
}
else {
_ttype = NUM_FLOAT;
}
}
)?
;
// a couple protected methods to assist in matching floating point numbers
protected
EXPONENT
: ('e'|'E') ('+'|'-')? ('0'..'9')+
;
protected
FLOAT_SUFFIX
: 'f'|'F'|'d'|'D'
;
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -