как успешно протестировать мою грамматику antlr4? [Дубликат]

Как было сказано в другом месте несколькими людьми, Java-программа запускается на более старой версии Java, чем та, для которой она была скомпилирована. Он должен быть «скомпилирован» для обратной совместимости. Другими словами, существует несоответствие между исходными и целевыми версиями Java.

Изменение параметров в меню Eclipse не отвечает на исходный плакат, который сказал, что он / она не использует Eclipse. В OpenJDK javac версии 1.7 вы можете перекрестно скопировать для 1.6, если вы используете параметры -source и -target, плюс укажите rt.jar -файл целевой версии (то есть более старую) во время компиляции. Если вы действительно установите 1.6 JRE, вы можете указать на его установку (например, /usr/lib/jvm/java-6-openjdk-i386/jre/lib/rt.jar на Ubuntu, / usr / jdk / jdk1. 6.0_60 / jre / lib / rt.jar на SunOS. Извините, я не знаю, где он находится в системе Windows). Например:

javac -source 1.6 -target 1.6 -bootclasspath /usr/lib/jvm/java-6-openjdk-i386/jre/lib/rt.jar HelloWorld.java

Похоже, вы можете просто скачать rt.jar из Интернета и указать на него. Это не слишком элегантно, хотя:

javac -source 1.6 -target 1.6 -bootclasspath ./rt.jar HelloWorld.java
17
задан Chiune Sugihara 21 April 2015 в 16:15
поделиться

1 ответ

Это кажется распространенным недоразумением ANTLR:

Обработка языка в ANTLR:

Обработка языка выполняется в двух строго разделенных фазах:

  • Лексинг, то есть разбиение текста на токены
  • Анализ, т. е. построение дерева разбора из токенов

Поскольку лексирование должно предшествовать синтаксическому анализу, возникает следствие : Lexer не зависит от анализатора, парсер не может влиять на лексику.

Лексинг

Лексинг в ANTLR работает следующим образом:

  • все правила с верхний регистр первого слова - это правила lexer
  • , лексер начинается с начала и пытается найти правило, которое наилучшим образом соответствует текущему входу
  • , наилучшее совпадение - это совпадение с максимальной длиной, т.е. токен, полученный из добавления следующего входного символа к совпадению максимальной длины, не сопоставляется никаким лексерским правилам
  • токены генерируются из совпадений: если одно правило соответствует максимальной длине совпадения, соответствующий токен равен pu пролить в поток токенов, если несколько правил соответствуют максимальной длине, соответствует первому определенному токену в грамматике, толкается в поток токенов

Пример: что не так с вашей грамматикой

Ваша грамматика имеет два правила, которые являются критическими:

FILEPATH: ('A'..'Z'|'a'..'z'|'0'..'9'|':'|'\\'|'/'|' '|'-'|'_'|'.')+ ;
TITLE: ('A'..'Z'|'a'..'z'|' ')+ ;

Каждое совпадение, соответствующее TITLE, также будет соответствовать FILEPATH. И FILEPATH определяется до TITLE: Таким образом, каждый токен, который вы ожидаете стать заголовком, будет FILEPATH.

Для этого есть два намека:

  • сохранить ваши правила лексера disjunct (никакой токен не должен соответствовать надмножеству другого).
  • , если ваши жетоны преднамеренно соответствуют тем же строкам, а затем помещают их в правильном порядке (в вашем случае этого будет достаточно).
  • , если вам нужен лексер, управляемый парсером, вам нужно перейти на другой генератор парсера: PEG-Parsers или GLR-Parsers сделают это (но, конечно, это может вызвать другие проблемы).
37
ответ дан A_Matar 20 August 2018 в 21:39
поделиться
  • 1
    Это имеет большой смысл сейчас, спасибо за ваш ответ! Было бы неплохо иметь более полезное сообщение об ошибке, но я знаю, что это может быть трудно или необоснованно. – Chiune Sugihara 21 April 2015 в 19:51
  • 2
    Во время выполнения анализатор должен предположить, что пользователь знает о его поведении. Однако я согласен с тем, что предупреждение будет прекрасным, если два правила лексера перекрываются таким образом. – CoronA 21 April 2015 в 19:55
  • 3
    Отличное резюме из ссылки ANTLR! – Cody 30 March 2017 в 11:35
  • 4
    Отличный ответ, спасибо. – Daniel Smith 30 May 2017 в 12:41
  • 5
    У меня была такая же проблема по другой причине. Константы токена в синтаксическом анализаторе и лексере были не синхронизированы, что привело к разным числам для «х» в обоих. Токены были правильно распознаны, но парсер не мог сравниться. Уборка проекта помогла. – avidD 11 August 2018 в 05:52
Другие вопросы по тегам:

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