RFR: JDK-8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW
Jan Lahoda
jan.lahoda at oracle.com
Fri Jul 26 15:25:54 UTC 2019
Hi,
Consider code like this:
---
public class T {
v + v n;
}
---
javac's parser will parse this as a variable of type "v" without a name,
and another variable of type "v" with a name "n", skipping the "+".
But if the code is:
---
public class T {
v += v n;
}
---
(note the change of '+' to compound assignment '+='), javac will parse
it as a variable with name "n" and type "v += v" and allows the
compilation to continue to Attr, where it eventually fails with:
---
java.lang.AssertionError: Unexpected tree: v += v with kind:
PLUS_ASSIGNMENT within: v += v with kind: PLUS_ASSIGNMENT
at
jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:162)
at
jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.validateAnnotatedType(Attr.java:5154)
at
jdk.compiler/com.sun.tools.javac.comp.Attr$TypeAnnotationsValidator.visitVarDef(Attr.java:5000)
...
---
It seems the reason for this difference is incorrect reliance on
operator priorities in JavacParser.term(). The proposed fix is to ignore
compound operators in type mode in term(), and hence treat += similarly
to +, parsing "v += v n;" as two variables, skipping '+='.
Part of the problem in the original testcase is insufficient error
recovery for parsing broken enums, I've split that into a separate bug -
JDK-8228647.
JBS: https://bugs.openjdk.java.net/browse/JDK-8228451
Webrev: http://cr.openjdk.java.net/~jlahoda/8228451/webrev.00/
How does this look?
Thanks,
Jan
More information about the compiler-dev
mailing list