問題タブ [dangling-else]

現在、私の楽しいプロジェクトをパーサーとして bison/flex に移行していますが、reduce/reduce の競合を解決するのに問題があります。

注: code_ で始まるものは中間アクションです

これを適切に解決する方法と、「頼りになる」解決策が間違っているか、機能しなかった理由を誰かに説明してもらえますか? ありがとう、X39

(生成された) 文法を Beaver パーサー ジェネレーターに供給しています。複数の shift-reduce の競合は、このルールで他にぶら下がっているように見えるために発生します。

ツールはデフォルトでSHIFTを選択するため、ダングリングelseは問題にならないと思いました。これは、ダングリングelse問題の解決策として受け入れられています。ただし、他に 16 個の警告があり、その理由がわかりません。

その結果、StatementArray3 では、else ブランチにごみが挿入されます (完全に間違った型、Optional ではなく List であり、次のステートメントからのむさぼり食ったものでいっぱいです)。誰かが私に説明してもらえますか? 文法はクラスモデルから生成されるため、この問題に対する非常に具体的な解決策は最善ではありません。この種の問題を一般的に解決するか、文法を変更する必要があります。

別の方法で生成された以前の文法 (避けたい) から、次の文法が得られます。

ただし、次の入力については、コンパイル中に競合は発生しません。

パーサーは実行時に失敗し、else をスキップして 2 番目の代入をトップレベルとして扱います。

問題のある完全な文法 (%import、%typeof、および を取り除いたもの{: ... :}):