RFR: 8273039: JShell crashes when naming variable or method "abstract" or "strictfp"

Jan Lahoda jlahoda at openjdk.java.net
Fri Nov 5 18:30:33 UTC 2021


On Fri, 5 Nov 2021 15:27:32 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> When JShell processes `int strictfp = 0;` (which is obviously erroneous), it will speculativelly try to parse and attribute code along these lines:
>> 
>> package REPL;
>> import java.io.*;import java.math.*;import java.net.*;import java.nio.file.*;import java.util.*;import java.util.concurrent.*;import java.util.function.*;import java.util.prefs.*;import java.util.regex.*;import java.util.stream.*;
>> class $JShell$DOESNOTMATTER {
>>     public static Object do_it$() throws Throwable {
>>         return int strictfp = 0;
>>     }
>> }
>> 
>> 
>> This crashes `Attr`, as the `strictfp` will be wrapped in `JCModifiers`, wrapped inside an erroneous tree, and `Attr` does not handle modifiers.
>> 
>> The proposal is to let `Attr` "handle" the `JCModifiers` in an error-recovery situation.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5101:
> 
>> 5099: 
>> 5100:     @Override
>> 5101:     public void visitModifiers(JCModifiers tree) {
> 
> question can't we report this error when the erroneous code is being parsed? adding this method to Attr makes me feel a bit uncomfortable, I can understand if this is the only / best way though

Parser will report the error, and will wrap the (presumed) modifiers into an erroneous tree, so the AST is reasonable. But JShell runs javac with `--should-stop=at=FLOW`, so the error in parser will not stop the processing, and when `Attr` will look into the erroneous tree, it will fail.

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

PR: https://git.openjdk.java.net/jdk/pull/5897


More information about the compiler-dev mailing list