RFR: JDK-8228451: NPE in Attr.java when -XDshould-stop.ifError=FLOW
Jonathan Gibbons
jonathan.gibbons at oracle.com
Mon Mar 2 15:21:23 UTC 2020
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
More information about the compiler-dev
mailing list