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

[Jonathan Gibbons]

Without having yet looked at the full webrev, the approach in webrev.00b 
to create a different sort of AST node looks good.

-- Jon


On 3/28/18 10:29 AM, Jan Lahoda wrote:
> 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
>>