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