ANTLR3 rule eval has non-LL(*) decision -



ANTLR3 rule eval has non-LL(*) decision -

here grammer:

grammar esi_exp; /* entry point of our parser. */ eval : booleanexp ; /* add-on , subtraction have lowest precedence. */ booleanexp : orexp ; orexp : andexpr (or andexpr)* ; andexpr : notexpr (and notexpr)* ; notexpr : not comparisonexpr | comparisonexpr ; comparisonexpr : varorliteral ('==' varorliteral)* ; varorliteral : functionexpr | literalexpr | variableexpr ; literalexpr : quote var_id quote ; variableexpr : open_var var_id close_paren // $(http_host) | open_var varwitharg close_paren // $(query_string{param}) | open_var varwithargquoted close_paren // $(query_string{'param'}) | open_paren booleanexp close_paren ; varwitharg : var_id open_arg var_id close_arg ; varwithargquoted : var_id open_quoted_arg var_id close_quoted_arg ; matchvalue : match_value_regex ; functionexpr : '$' functionname functionargs; functionname : 'exists' | 'is_empty' ; functionargs : '()' | open_paren var_id close_paren | open_paren variableexpr close_paren ; equals : '==' ; match_func : 'matches' ; triple_quote : '\'\'\'' ; quote : '\'' ; open_var : '$(' ; open_paren : '(' ; close_paren : ')' ; open_arg : '{' ; close_arg : '}' ; open_quoted_arg : '{\'' ; close_quoted_arg : '\'}' ; var_id : ('a'..'z'|'a'..'z'|'_')+ ; // match identifiers , : '&&' | '&' ; or : '|' | '||' ; not : '!' ; /* number: can integer value */ number : ('0'..'9')+ ; ws : ( ' ' | '\r' | '\t' | '\u000c' | '\n' ) { skip(); } ; match_value_regex : triple_quote ~(quote)* triple_quote;

which works great test case:

$exists($(id)) && (($(pagetype) == 'roster') || ($(pagetype) == 'cheerleaders') || ($(pagetype) == 'coaches') || ($(pagetype) == 'staff'))

however, need have able recognize:

$(request_path) matches '''(matchup)/([^/]*)/([^/]*)/([^/]*)/([^/]*)'''

a grammar rule like:

varorliteral match_func matchvalue

should match , result in parsed grammar. rule working in before version taken out when reworked grammar back upwards enclosing parens in expression.

i've read enabling backtracking should able help in these situations documentation seems indicate backtracking should avoided in general.

how add together without having ll and/or left recursion issues?

you can anticipate expect origin of rule in order specify way.

why don't seek this?

varorliteral : (quote quote) => matchvalue |(quote) => literalexpr | variableexpr |functionexpr ;

with this, telling grammar if varorliteral begins quote, literalexpr. etc.

you can anticipate how many want.

last rule, default option.

good luck!

antlr3 ll

Comments

Popular posts from this blog

formatting - SAS SQL Datepart function returning odd values -

c++ - Apple Mach-O Linker Error(Duplicate Symbols For Architecture armv7) -

php - Yii 2: Unable to find a class into the extension 'yii2-admin' -