RustPython / RustPython/Parser
Error recovery/resilience
還沒有人認領這個 Issue。
- 主要語言
- Rust
- 星號
- 117
- 分支
- 38
- 平均合併
- 4 天 7 小時
- 30 天內合併 PR
- 1
描述
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?
貢獻指南
這個儲存庫沒有索引到貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
先閱讀 parser 的 parse 函式,以及它們目前如何回傳 Result<ast, ParseError>。檢視連結的 LALRPOP 與 resilient-LL parsing 資料,以比較錯誤復原方式。完成的標準是:專案已就錯誤復原是否屬於範圍達成共識;若屬於範圍,則已有保留成功解析部分的具體設計。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- rust
- 領域
- compilers
- Issue 類型
- 功能
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 停滯
- 描述清晰度
- 需要釐清
- 新手友好度
- 25/100