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