RFR: JDK-8200166: Repeating annotations refering to to-be-generated classes don't work.

[Jonathan Gibbons]

It seems surprising that a JCErroneous tree is used in this context. The 
syntax is well-formed; the problem is a semantic one of "name not found".

"Expression not allowed"    would seem to apply to something like

     @Annot(System.out)

But

     @Annot(DoesNotExist.class)

Should be "Name not found".

-- Jon


On 3/28/18 8:42 AM, Jan Lahoda wrote:
> Hi,
>
> javac in JDK 10 does not handle properly repeating annotations that 
> contain attributes referring to classes that are generated by an 
> annotation processor. E.g.:
> ---
> @Annot(Gen.class)
> @Annot(Gen.class)
> public class GeneratedInRepeating {
> }
> ---
>
> (where "Annot" is a repeating annotation, and "Gen" is a class 
> generated by an annotation processor). This will fail to compile with 
> (please see the bug for a complete example):
> ---
> ... error: expression not allowed as annotation value
> @Annot(Gen.class)
> ---
>
> The annotation processors won't run, so won't have a chance to 
> generate the class.
>
> The issue is that Annotate.processRepeatedAnnotations creates a 
> synthetic container annotation for the repeating annotation, 
> constructs an AST for it and tries to attribute it (Annotate lines 
> 821-832). But when the AST is created, as the class in the attribute 
> value is missing, there is an JCErroneous tree generated. And then 
> when Annotate.attributeAnnotationValue checks if the attribute's value 
> is well-formed, it finds the erroneous tree and barks.
>
> The code was refactored in JDK-8181464, and was (AFAIK) accepting 
> erroneous trees without producing the error before that.
>
> The proposed fix is to ignore the erroneous trees again. If there's an 
> erroneous tree, there should have been an error produced already, so 
> ignoring erroneous trees seems safe.
>
> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200166
>
> Thanks,
>     Jan