ANTLR: слишком большое разрешение кода в статическом инициализаторе корневой грамматики - PullRequest
Новая
       1

ANTLR: слишком большое разрешение кода в статическом инициализаторе корневой грамматики

0 голосов
/ 03 ноября 2011

В поисках решения моей проблемы я получил этот вопрос , предлагая составные грамматики, чтобы избавиться от code too large. Проблема там, я уже использую импорт грамматики, но когда я продолжаю расширять одну из импортированных грамматик, грамматика корневого парсера показывает ошибку. По-видимому, проблема заключается во многих определениях токенов и DFA, которые ANTLR генерирует после анализа всей грамматики. Есть ли способ / как это предлагается, чтобы избавиться от этой проблемы? Является ли он масштабируемым, т. Е. Не зависит от того, какие части были изменены из-за того, что обходной путь достаточно мал?

РЕДАКТИРОВАТЬ: Чтобы прояснить это (связанный вопрос не прояснил): Ошибка code too large - это ошибка компилятора в сгенерированном коде синтаксического анализатора, на мой взгляд, обычно вызванная грамматикой настолько большой, что некоторый код больше, чем предел спецификации Java. В моем случае это статический инициализатор корневого класса синтаксического анализатора, который содержит тонны переменных предпросмотра DFA, и все это приводит к коду в инициализаторе. Таким образом, в идеале, ANTLR должна быть в состоянии разделить это на случай, если грамматика слишком велика / пользователь говорит ANTLR сделать это. Есть ли такая опция?

(Должен признать, у автора вопроса, связанного с вопросом, было ... интересное правило, которое приводило к тому, что его грамматика раздваивалась, и это может быть моей ошибкой и здесь. Но возможность это не ошибка автора грамматики (в любой большой грамматике), так что я вижу это как правильный, не относящийся к грамматике вопрос ANTLR)

РЕДАКТИРОВАТЬ КОНЕЦ

Моя грамматика разбирает текст правил "Магическое Собрание" и доступна здесь (git). Проблема, в частности, возникает при замене строки 33 на 34-36 в этом файле . Я использую Maven и antlr3-maven-plugin для сборки, поэтому в идеале, обходной путь выполним с помощью плагина, но если это не так, это меньшая проблема, чем у меня сейчас ...

Большое спасибо, и я надеюсь, что я не наблюдал ни одной очевидной документации, которая бы мне помогла.

1 Ответ

1 голос
/ 04 ноября 2011

Ключевое слово fragment может использоваться только до правил лексера, не до правил синтаксического анализатора, как я вижу у вас.Сначала измените это во всех ваших грамматиках (я смотрел только на ObjectExpressions.g).К сожалению, ANTLR не выдает ошибку, когда вы пытаетесь это сделать.Но поверьте мне: это неправильно и может быть причиной (частью) ваших проблем.

Кроме того, ваше правило из строки 34-36: 

qualities
  :  qualities0 
  |  qualities0 (COMMA qualities0)+ -> qualities0+ 
  |  qualities0 (Or qualities0)+    -> ^(Or qualities0+)
  ;

должно быть переписаноas: 

qualities
  :  qualities0 (COMMA qualities0)* -> qualities0+ 
  |  qualities0 (Or qualities0)+    -> ^(Or qualities0+)
  ;

EDIT

Итак, в идеале, ANTLR должна иметь возможность разделить это в случае, если грамматика слишком большая / пользователь говорит ANTLR сделать это,Есть ли такая опция?

Нет, такой опции, к сожалению, нет.Вам придется разделить грамматику на (даже более) меньшие.

...