нет жизнеспособной альтернативы при вводе 'int' - ANTLR 4 с парсером Python - PullRequest
Новая
       14

нет жизнеспособной альтернативы при вводе 'int' - ANTLR 4 с парсером Python

0 голосов
/ 09 апреля 2019

У меня возникла проблема при работе с ANTLR4 и Parse by Python Library.

Грамматика: 

grammar SimpleCode;           
program  : 'class' ' ' 'Program' ' ' '{'  field_decl* method_decl*  '}' ;
field_decl : DATA_TYPE variable (',' variable)* ';' ;
method_decl: (DATA_TYPE | 'void')  identifier '(' method_params? ')' block ;
variable : identifier | identifier '[' int_literal ']' ;
method_params : DATA_TYPE identifier (',' DATA_TYPE identifier)* ;
block : '{' var_decl* statement* '}' ;
var_decl : DATA_TYPE identifier (',' identifier)* ';';
statement : location assign_op expr ';' | method_call ';' | 'if' '(' (expr) ')' block ('else' block)? | 'for' identifier '=' (expr) ',' (expr) block | 'return' (expr)? ';' | 'break' ';' | 'continue' ';' | block ;
assign_op : '=' | '+=' | '-=' ;
method_call : method_name '(' method_call_params? ')' | 'callout' (string_literal (',' callout_arg (',' callout_arg)*)?) ;
method_call_params : DATA_TYPE identifier (',' DATA_TYPE identifier)* ;
method_name : identifier ;
location : identifier | identifier '[' expr ']' ;
expr : location | method_call | literal | expr bin_op expr | '-' expr | '!' expr | '(' expr ')' ;
callout_arg : expr | string_literal ;
bin_op : arith_op | rel_op | eq_op | cond_op ;
arith_op : '+' | '-' | '*' | '/' + '%' ;
rel_op : '<' | '>' | '<=' | '>=' ;
eq_op : '==' | '!=' ;
cond_op : '&&' | '||' ;
literal : int_literal | char_literal | bool_literal ;
identifier : ALPHA alpha_num* ;
alpha_num : ALPHA | DIGIT ;
int_literal : decimal_literal | hex_literal ;
decimal_literal : DIGIT DIGIT* ;
hex_literal : '0x' HEX_DIGIT HEX_DIGIT* ;
bool_literal : 'true' | 'false' ;
CHAR: . ;
char_literal : '\'' CHAR '\''  ;
string_literal : '"' CHAR* '"' ;


DATA_TYPE : INT | BOOL ;

INT : 'int' ;
BOOL : 'boolean' ;
ALPHA : [a-zA-Z] ;
DIGIT : [0-9] ;
HEX_DIGIT : [0-9a-fA-F] ;

White : [ \t]+ -> skip ;
Newline : ( '\r' '\n'? | '\n' ) -> skip ;
LineComment : '//' ~[\r\n]* -> skip ;

Мой код Python для разбора: 

from antlr4 import *
from SimpleCodeLexer import SimpleCodeLexer
from SimpleCodeListener import SimpleCodeListener
from SimpleCodeParser import SimpleCodeParser
import sys

class SimpleCodePrintListener(SimpleCodeListener):
    def enterProgram(self, ctx):
        print(ctx.getText())
        print(ctx.toStringTree())
        # for child in ctx.getChildren():
        #     print(child.getText(), child.getSymbol())

def main():
    input_stream = FileStream('in.in')
    lexer = SimpleCodeLexer(input_stream)
    stream = CommonTokenStream(lexer)
    parser = SimpleCodeParser(stream)
    tree = parser.program()
    printer = SimpleCodePrintListener()
    walker = ParseTreeWalker()
    walker.walk(printer, tree)

if __name__ == '__main__':
    print('Starting parse....')
    main()

И файл in.in : 

class Program {
    int main() {
        int v;
        v = 1;
        v = 'c';
        v = true;
        return 0; 
    }
}

Я получил эту ошибку после запуска кода Python:

строка 2: 7 - нет приемлемой альтернативы на входе 'int'

Результат первого отпечатка:

Класс Program {int main () {int v; v = 1; v = 'c'; v = true; return 0; }} 

([] class   Program   { int   m a i n ( )   { int   v ; v   =   1 ; v   =   ' c ' ; v   =   true ; return   0 ;   } })

Я новичок в ANTLR4, поэтому есть ли какой-то особый случай для работы с лексерами и токенами, потому что после нескольких часов поиска в интернете, основная проблема в том, что DATA_TYPE используется во многих разных местах в грамматике.

1 Ответ

1 голос
/ 09 апреля 2019

При отладке подобных проблем часто помогает распечатать поток токенов, сгенерированный для данного ввода.Вы можете сделать это, запустив grun с параметром -tokens или итерировав stream в вашей функции main.

Если вы сделаете это, вы увидите, что main является токенизированнымкак последовательность из четырех CHAR токенов, тогда как ваше правило identifier ожидает ALPHA токенов, а не CHAR.Так что это непосредственная проблема, но это не единственная проблема в вашем коде:

  • Первое, что я заметил, когда попробовал ваш код, это то, что я получил ошибки при переносе строк.Причина, по которой это происходит для меня, а не для вас, (предположительно) в том, что вы используете разрывы строк в Windows (\r\n), а я нет.Ваш лексер распознает \r\n как разрыв строки и пропускает его, но просто \n распознается как CHAR.

  • Кроме того, обработка пробелов очень запутанна.Одиночные пробелы являются их собственными токенами.Они должны появляться в определенных местах и ​​не могут появляться где-либо еще.Однако несколько последовательных пробелов пропускаются.Так что что-то вроде int main будет ошибкой, поскольку не будет обнаруживать пробел между int и main.С другой стороны, отступ строки с одним пробелом был бы ошибкой, потому что тогда отступ не был бы пропущен.

  • Ваши идентификаторы также бесполезны.Идентификаторы могут содержать пробелы (если их больше одного), разрывы строк (если они \r\n или вы исправили это, так что \n также пропускается) или комментарии.Таким образом, следующее будет одним действительным идентификатором (при условии, что вы измените лексер, чтобы буквы распознавались как ALPHA вместо CHAR): 

    hel  lo  //comment
wor
ld

    С другой стороны, maintarget будетне может быть действительным идентификатором, поскольку он содержит ключевое слово int.

  • Аналогичным образом пропущенные токены также можно использовать внутри целочисленных литералов и строковых литералов.Для строковых литералов это означает, что "a b" является допустимой строкой (что хорошо), которая содержит только символы a и b (что не хорошо), поскольку двойной пробел пропускается.С другой стороны, " " будет недопустимой строкой, поскольку распознается как токен ' ', а не как CHAR.Также, если вы исправите свои идентификаторы, сделав буквы распознаваемыми как ALPHA, они больше не будут действительны внутри строк.Также "la//la" будет рассматриваться как незамкнутый строковый литерал, поскольку //la" будет рассматриваться как комментарий.

Все эти проблемы связаны с тем, как работает лексер, поэтому давайте пройдемся почто:

При преобразовании потока символов в поток токенов лексер будет обрабатывать ввод в соответствии с правилом "максимального мунка": он пройдет все правила лексера и проверит, какое из них соответствуетв начале текущего ввода.Из тех, которые совпадают, он выберет тот, который даст самый длинный матч.В случае связей он предпочтет тот, который определен первым в грамматике.Если вы используете строковые литералы непосредственно в правилах синтаксического анализатора, они обрабатываются как правила лексера, которые определены раньше других.

То есть, у вас есть правило CHAR: .;, которое предшествует ALPHA, DIGITи HEX_DIGIT означает, что эти правила никогда не будут совпадать.Все эти правила соответствуют одному символу, поэтому, когда более чем одно из них соответствует, CHAR будет предпочтительным, потому что оно стоит первым в грамматике.Если вы переместитесь на CHAR до конца, буквы теперь будут соответствовать ALPHA, десятичные цифры DIGIT и все остальное CHAR.Это по-прежнему оставляет HEX_DIGIT бесполезным (и если вы переместите его вперед, это сделает ALPHA и DIGIT бесполезным), а также означает, что CHAR больше не делает то, что вы хотите, потому что вы хотите цифр и букв, которые следует рассматривать как CHAR с, но только внутри строк.

Настоящая проблема здесь в том, что ни одна из этих вещей не должна быть токеном.Они должны быть либо fragment s, либо просто вставлены непосредственно в правила лексера, которые их используют.Вместо этого ваши токены должны быть такими, внутри которых вы не хотите разрешать / игнорировать пробелы или комментарии.Поэтому строковые литералы, литералы int и идентификаторы должны быть токенами.Единственный случай, когда у вас есть несколько правил лексера, которые могут соответствовать одному и тому же вводу, должны быть идентификаторами и ключевыми словами (где ключевые слова имеют приоритет над идентификаторами, потому что вы задаете их как строковые литералы в грамматике, но более длинные идентификаторы могут по-прежнему содержать ключевые слова в качестве подстроки из-замаксимальное правило munch).

Вы также должны удалить из своей грамматики все случаи использования ' ' и вместо этого всегда пропускать пробелы.

...