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

Jan Lahoda jan.lahoda at oracle.com
Wed Mar 28 17:29:42 UTC 2018


On 28.3.2018 17:49, Jonathan Gibbons wrote:
> 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".

When the parser sees it, it gets parsed OK. But when the annotation is 
attributed the missing class is modelled as Attribute.UnresolvedClass (a 
subclass of Attribute.Error).

Then the repeating annotation framework takes this, wraps the annotation 
into the container annotation and creates a new AST for the 
attributes/compounds, which writes the 
Attribute.UnresolvedClass/Attribute.Error as JCErroneous. And when the 
new AST is reattributed using Annotate.attributeAnnotationValue, it will 
fail on that.

I guess an alternate fix may be this:
http://cr.openjdk.java.net/~jlahoda/8200166/webrev.00b/

Jan

>
> -- 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
>


More information about the compiler-dev mailing list