Error recovery/resilience

オープン
#68 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
rust
領域
compilers

調査の方向性

まず、パーサーの parse 関数と、それらが現在どのように Result<ast, ParseError> を返しているかを読みます。リンクされている LALRPOP と resilient-LL parsing の資料を確認し、エラー回復のアプローチを比較します。エラー回復を対象範囲に含めるかどうかについてプロジェクトとして合意された判断があり、含める場合は、正常にパースされた部分を保持するための具体的な設計があることが完了の条件です。

索引モデルが issue の本文から書いたものです。

説明

Currently, all of the parse functions return Result<ast, ParseError>. This means that if the file has a syntax error, we get the error and nothing else. However, there are some use cases in which having access to parts which did parse successfully would be beneficial:

  • Language servers usually want to keep functioning when the file is temporarily broken during editing.
  • Linters might want to skip over broken parts and continue reporting lints, or maybe up to the syntax error.

On the other hand, interpreters usually don't have too much use for this AFAIK.

lalrpop seems to have some support for error recovery: https://lalrpop.github.io/lalrpop/tutorial/008_error_recovery.html
Alex Kladov has written about error recovery, most recently here: https://matklad.github.io/2023/05/21/resilient-ll-parsing-tutorial.html

Is RustPython/Parser interested in error recovery or is it out of scope?

主要言語
Rust
スター
117
フォーク
38
平均マージ
4日 7時間
マージ済み PR（30日）
1

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

RustPython/Parser のほかの issue

RustPython/Parser の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。