«FOLLOW_set_in_»… не определено в сгенерированном парсере

Я написал грамматику для неопределенного Java-подобного DSL. Хотя с ним все еще есть некоторые проблемы (он не распознает все входные данные так, как я бы этого хотел), меня больше всего беспокоит то, что сгенерированный код C не компилируется.

Я использую AntlrWorks 1.5 с Antlr 3.5 (очевидно, что Antlr 4 не поддерживает цель C).

Проблема с правилами выражения. У меня есть правила prio14Expression к prio0Expression, которые обрабатывают приоритет оператора. Проблема имеет приоритет 2, который оценивает префиксные и постфиксные операторы:

...
prio3Expression: prio2Expression (('*' | '/' | '%') prio2Expression)*;

prio2Expression: ('++' | '--' | '!' | '+' | '-')* prio1Expression ('++' | '--')*;  

prio1Expression:
    prio0Expression (
        ('.' prio0Expression) |
        ('(' (expression (',' expression)*)? ')') |
        ('[' expression (',' expression)* ']')
    )*;

prio0Expression: 
    /*('(') => */('(' expression ')') |
    IDENTIFIER |
    //collectionLiteral |
    coordinateLiteral |
    'true' |
    'false' |
    NUMBER |
    STRING 
    ;
...

Выражение - это метка для prio14Expression. Вы можете увидеть полную грамматику ---- +: = 2 =: + ----".

Я сделал что-то не так в грамматике? Никакие другие правила не вызывают эту ошибку, и если я несколько переформулирую соответствующее правило, сгенерированный код будет действительным (но тогда грамматика не будет делать то, что я хочу). Что я могу сделать, чтобы решить эту проблему?

Спасибо за любую помощь.

7 голосов | спросил Matěj Zábský 19 22013vEurope/Moscow11bEurope/MoscowTue, 19 Nov 2013 00:20:19 +0400 2013, 00:20:19

2 ответа


0

Я столкнулся с той же проблемой.

Я думаю, что это происходит, если правило синтаксического анализатора имеет часть простого OR-ed-токена, например:

problem_case: problematic_rule;
problematic_rule: 'A' | 'B' ;

Этого не произойдет, если это правило лексера.

workaround1: As_lexer_rule;
As_lexer_rule: 'A' | 'B' ;

Или, если это сложное правило (не простой OR-ed токен).

workaround2: make_it_complicated_needlessly;
make_it_complicated_needlessly: 'A' | 'B' | {false}? NeverUsedRule;
NeverUsedRule: /* don't care*/ ;

(Я использовал семантический предикат "{false}?" для этой модификации. Я считаю, что это не меняет грамматику целевого языка.)

ответил naqtn 10 Jpm1000000pmFri, 10 Jan 2014 12:59:29 +040014 2014, 12:59:29
0

это, кажется, старый пост, но все же, может быть, он все еще полезен для кого-то (как это было для меня).

Я столкнулся с той же проблемой во время выполнения C в antlr 3.5.

еще один простой обходной путь, который не меняет грамматику:

problem_case: problematic_rule;
problematic_rule: a='A' | b='B' ;
ответил lp_ 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 16 Sep 2014 20:04:52 +0400 2014, 20:04:52

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132