RFR: 8324859: Improve error recovery [v3]

[Maurizio Cimadamore]

On Tue, 20 Aug 2024 13:55:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider code like:
>> 
>> package tests;
>> public class TestB {
>>     public static boolean test() // <--- missing open brace
>>         return true;
>>     }
>>     public static boolean test2() {
>>         return true;
>>     }
>> }
>> 
>> 
>> In JDK 17, it used to produce 3 compile-time errors:
>> 
>> $ javac  /tmp/TestB.java 
>> /tmp/TestB.java:3: error: ';' expected
>>     public static boolean test() // <--- missing open brace
>>                                 ^
>> /tmp/TestB.java:6: error: class, interface, enum, or record expected
>>     public static boolean test2() {
>>                   ^
>> /tmp/TestB.java:8: error: class, interface, enum, or record expected
>>     }
>>     ^
>> 3 errors
>> 
>> 
>> Currently, it produces 4:
>> 
>> $ javac  /tmp/TestB.java 
>> /tmp/TestB.java:3: error: ';' expected
>>     public static boolean test() // <--- missing open brace
>>                                 ^
>> /tmp/TestB.java:6: error: implicitly declared classes are a preview feature and are disabled by default.
>>     public static boolean test2() {
>>                   ^
>>   (use --enable-preview to enable implicitly declared classes)
>> /tmp/TestB.java:9: error: class, interface, enum, or record expected
>> }
>> ^
>> /tmp/TestB.java:1: error: implicitly declared class should not have package declaration
>> package tests;
>> ^
>> 4 errors
>> 
>> 
>> Neither of these is particularly nice. The common property is that the javac's parser "de-synchronizes" on the missing opening brace (`{`), and consumes the first closing brace (`}`) as a closing brace for the class (not for the method), causing all the follow-up behavior.
>> 
>> In general, the javac's parser handles missing closing braces fairly well - it skips tokens until it find something it can synchronize on, and continues. But, it does not handle missing opening braces as well, and has tendency to get lost in the input.
>> 
>> For the case above, it would be much better if javac parsed the code following the missing opening brace as a block.
>> 
>> This patch is attempting to do that, without making other cases I was able to find (much) worse. The overall approach is to skip tokens until a statement or member start is found, and then look at what follows:
>> - if it is an opening brace, parse the follow up as a block
>> - if it is a statement keyword (like `if`), parse the follow up as a block,
>> - if it is a closing brace, see if injecting a virtual opening brace at the current position would balance the opening/closing braces in the rest of the...
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Update src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8324859
>  - Reflecting feedback - separating the estimation logic into a separate method.
>  - More cases.
>  - Improving error message for attributes with default value.
>  - Handling another testcase.
>  - Merge branch 'master' into JDK-8324859
>  - Tweaking the error recovery.
>  - 8324859: Improve error recovery

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20070#pullrequestreview-2248180312