問題タブ [glr]

Bison 2.7 を使用して GLR パーサーを作成し、%error-verbose オプションをオンにしています。パーサーを実行すると、「構文があいまいです」というエラーが表示されました。構文があいまいな場所/方法について、Bison が詳細を教えてくれる方法はありますか?

複数の文法例を試しましたが、生成されたファイルをコンパイルしようとすると同じエラーが発生します。

たとえば、この質問の解決策を正確にたどりました - GLR_Lib.hs: Could not find module 'System'

文法ファイルの場所

しかし、コンパイルすると次のようになります。

[1/2] ABCData のコンパイル ( ABCData.hs、ABCData.o )

[2/2] ABC のコンパイル ( ABC.hs、ANC.o )

GLR_Lib.hs:164:2: 入力 'case' の解析エラー</p>

この正確なエラーは、私が試したすべての文法で発生しました。私は、例がうまく機能している人々と何が違うのかわかりません。

GLR パーサーが正しく記述されているかどうかをテストするための完全な一連のテストはありますか?

私は GLR パーサーを書いているので、自分のコードのテストをいくつか見つけたいと思っています。おそらくいくつかの条件が欠落しているため、自分で完全なテスト スーツを理解することはできません。

パーサーをテストするためのテストをいくつか書きました。ただし、他の条件で失敗するかどうかはわかりません。したがって、「完全なテスト」が必要です。多くの人がテストケースをテストに追加する可能性があります。これにより、パーサーがあらゆるケースを処理できることが保証されます。GLR パーサーは任意の文脈自由文法を処理できるため、多くの条件をテストする必要があります。

現在、私は VHDL 用のパーサーを構築しようとしていますが、これには C++ パーサーが直面しなければならない問題がいくつかあります。VHDL の文脈自由文法は、関数呼び出しと配列サブスクリプションに関するあいまいさのため、単一の解析ツリーではなく解析フォレストを生成します。

この代入は、パーサーが曖昧さを多少オンザフライで解決するために使用する、階層的に型を認識するシンボル テーブルを保持する場合にのみ、明確に解析できます。

前述のようなステートメントの場合、解析フォレストは指数関数的に成長するのではなく、関数呼び出しと配列サブスクリプションの量に応じて線形になるため、これを行いたくありません。

（もちろん、次のようなステートメントでパーサーを苦しめることを除いて）

bison はユーザーに単一の解析ツリーを作成することを強制するため、%merge 属性を使用してすべてのサブツリーを再帰的に収集し、シングルトン AST のいわゆる AMBIG ノードの下にそれらのサブツリーを追加しました。

結果は次のようになります。

上記を生成するために、トークン ストリーム「I=I(N);」を解析しました。parse.y ファイル内で使用した文法の内容を以下にまとめます。VHDL のあいまいな部分に似せようとします。

ソースコード全体は、この github リポジトリで読むことができます。

それでは、実際の問題に取り掛かりましょう。上記の生成された構文解析ツリーでわかるように、ノード FCALL1 と ARRIDX1 は同じ単一ノード EXPR1 を参照し、それは N1 を 2 回参照します。

これは、絶対に起こってはならないことであり、その理由はわかりません。代わりにパスがあるはずです

バイソンが前述のノードを再利用する理由がわかりましたか?

また、bison の公式 gnu メーリング リストにバグレポートを書きましたが、この点に対する返信はありませんでした。残念ながら、新しいスタックオーバーフロー ユーザーに対する制限により、このバグ レポートへのリンクを提供することはできません...