解析のテクニックは、CSの文献に詳しく説明されています。しかし、私が知っているアルゴリズムでは、ソースが構文的に正しいことが必要です。構文エラーが発生した場合、解析は直ちに中止されます。構文エラーのあるコードの解析
しかし、IDE（Visual Studioなど）は通常、意味のあるコード補完やその他のヒントを入力しながら、と入力すると、構文が有効な状態にないことがよくあります。例えば。関数呼び出しで開始括弧を入力すると、閉じ括弧が入力されるまで構文が無効であっても、IDEはその関数のパラメータヒントを提供します。
これは、ある種の推測またはエラー耐性パーサーに依存しなければならないようです。誰にどのようなテクニックやアルゴリズムが使用されているか知っていますか？
Packratは有望です.Packratはキーポイントでの成功した解析試行と失敗した解析試行の両方に関する情報を提供し、スマートエラーレポート、完了、ヒントなどのために回復して使用できます。たとえば、カーソルが、すべての解析試行がキャッシュ内で失敗としてマークされたポイントにある場合、試行したトークンのリストを完了オプションに指定できます。
標準的なやり方は、解析機械を使用して何らかのエラー修復を行い、予測を助けることです。
テーブルベースのパーサー（LALRやGLRなど）の場合、構文エラーが発生すると、パーサーは最近エラーが発生していない状態になっています。各シフトの前にこのことを覚えておくためにパーズスタックを記録することができます（あるいは、エラーの前にレコードを減らす）ことができます。エラーが発生した場合、保存されたスタックの解析状態を調べて、どのトークンが次に存在するかを判断できます（構文トークンのコード補完方法も同じです）。より洗練されたテクニックは、エラートークン、またはエラートークンを置き換えて次のものへの移行を可能にする可能性のある最小のツリーによるシフトを可能にするトークンの可能な最小シーケンスを発明することができる。
これは、述語を作成するための多くの情報が存在しないため、再帰的降下パーサーではあまり簡単ではありません。エラーリカバリでは、エラーリカバリポイント（例えば、 "stmt"が受け入れられる）を定義し、 ";"が見つかり、「エラーstmt」を受け入れます。コード補完が必要な場合、これは役に立ちません。