RFR: JDK-8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW

[Jonathan Gibbons]

Jan,

In the test, the regex \r*\n can/should be replaced by \R.

Otherwise, looks good.

-- Jon

On 7/26/19 8:25 AM, Jan Lahoda wrote:
> 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