HackerPapers

arXiv:1804.07133cs.PL

Don't Panic! Better, Fewer, Syntax Errors for LR Parsers

Lukas Diekmann, Laurence Tratt

Abstract

Syntax errors are generally easy to fix for humans, but not for parsers in general nor LR parsers in particular. Traditional 'panic mode' error recovery, though easy to implement and applicable to any grammar, often leads to a cascading chain of errors that drown out the original. More advanced error recovery techniques suffer less from this problem but have seen little practical use because their typical performance was seen as poor, their worst case unbounded, and the repairs they reported arbitrary. In this paper we introduce the CPCT+ algorithm, and an implementation of that algorithm, that address these issues. First, CPCT+ reports the complete set of minimum cost repair sequences for a given location, allowing programmers to select the one that best fits their intention. Second, on a corpus of 200,000 real-world syntactically invalid Java programs, CPCT+ is able to repair 98.37% of files within a timeout of 0.5s. Finally, CPCT+ uses the complete set of minimum cost repair sequences to reduce the cascading error problem, where incorrect error recovery causes further spurious syntax errors to be identified. Across the test corpus, CPCT+ reports 435,812 error locations to the user, reducing the cascading error problem substantially relative to the 981,628 error locations reported by panic mode.

arXiv comments
32 pages, 18 figures
Journal reference
DOI
Subjects
cs.PLProgramming Languages

On Hacker News

Linked by 2 identifiable commenters in 4 comments across 4 threads, from Nov 2018 to Jul 2020.

Comments linking this paper, per year.

Discussed in comments4 threads

    • Awesome. I love good research into parsing, since parsing is famously "the solved problem that isn't": https://tratt.net/laurie/blog/entries/parsing_the_solved_pro... I hope to study this paper well (which is by the author of the above post) and understand what their algorithm…

      bolluView on HNParent context

    • I completely agree: the poor quality of error reporting in parsing tools is a significant reason not to use them. When I started looking into this a couple of years back, what surprised me is how much work there's been in this spread over decades. Building upon that (and obvious…

      ltrattView on HNParent context

    • > They correctly point out that error handling is by far the biggest one, and usually ends up being the biggest part of a parser for a language, full of crufts and strange mixtures of semantics and syntax. Add to this that you frequently want to try to partially recover -- make…

      ltrattView on HNParent context

    • > The problem with yacc/bison-style LALR parser generators is that you end up with an LALR parser. Which works great on syntactically correct code, but trying to get a reasonable error message out of one is about as much fun as repeatedly poking yourself in the eye with a sharp…

      ltrattView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.