5

私はantlr3で機能するやや大きな文法でantlr4を試しています。必要な2つの文法変更を処理しました。これで、レクサーとパーサーを生成するツールができました。

ただし、レクサーにはコンパイルエラーがあります。

1）このタイプは、定数プールでUtf8形式でエンコードするために65535バイト以上を必要とする文字列を生成します

エラーはEclipseのクラス名に表示されるため、どの文字列について話しているのか正確にはわかりませんが、これは非常に長い文字列であると思われます。

    public static final String _serializedATN =
        "\1\2\u01c5\u1741\6\uffff\2\0\7\0\2\1\7\1\2\2\7\2\2\3\7\3\2\4\7\4\2\5\7"+
        "\5\2\6\7\6\2\7\7\7\2\b\7\b\2\t\7\t\2\n\7\n\2\13\7\13\2\f\7\f\2\r\7\r\2"+
... etc, etc (few hundred lines of unicode)

パーサジェネレータのバグのように見えますが、antlr4に必要な新しい設定がある可能性があります（？）

4

1 に答える 1

5

これは実際にはJavaの制限であり、ANTLRのバグではありません（正しいシリアル化文字列が作成されますが、Javaのエンコーディングではそれを保存できません）。先週、この問題を解決するために表現を微調整しました_serializedATNが、シリアル化されたフォームを複数の文字列に分割したり、実行時に読み込まれる別のファイルに保存したりすることを含む完全な回避策は実装していません。

必要なATNのサイズを小さくするために文法を微調整する方法はいくつかあるかもしれませんが、それを評価するには文法を見る必要があります。

更新： ANTLR 4.1以降_serializedATN、生成されたコードで一定のプール制限を超えないように、必要に応じて分割されるようになりました。詳細については、 76号を参照してください。

于 2013-01-17T15:23:22.143 に答える