RFR: JDK-8234101: Compilation error thrown when repeating annotation is used on record component

Jan Lahoda jan.lahoda at oracle.com
Wed Dec 11 17:54:59 UTC 2019


Looks OK to me for now.

But I wonder if we eventually shouldn't find a better place for the 
side-effects made in Check.validateAnnotation (i.e. tat "validate" would 
not have side-effects except for reporting errors).

Jan

On 11. 12. 19 5:40, Vicente Romero wrote:
> Hi,
> 
> Please review the fix for [1] at [2]. This patch provides support for 
> repeating annotations on records. It builds on the previous support for 
> annotations for records. Which is that all annotations applied to record 
> components are pushed down to all members generated by the compiler from 
> each record component: field, constructor parameter and accessor. Later 
> at Check::validateAnnotation if we have gone too far and had applied an 
> annotation to a non-applicable location, it is removed.
> 
> The idea of this patch is that when a repeated annotations are being 
> processed at Annotate::processRepeatedAnnotations, if the annotated 
> element is a record or a record member and the annotation is not 
> applicable to it, we bail out instead of issuing an error. Later on at 
> Check::validateAnnotation when we have all the information about the 
> annotations we can remove non-applicable annotations as before. But 
> there is an important detail Check::validateAnnotation, validates 
> annotations one by one, so if an annotation has been repeated kind of:
> 
> record R(@A @A int i) {}
> 
> then the method will be invoked twice for each appearance of @A, 
> currently Check::validateAnnotation can remove each instance, but we 
> also want to remove the container annotation which is synthetically 
> generated by javac. For this reason I have modified 
> SymbolMetadata::remove to remove a container annotation if at least one 
> of the contained annotations is removed. How does it looks?
> 
> Thanks,
> Vicente
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8234101
> [2] http://cr.openjdk.java.net/~vromero/8234101/webrev.00/


More information about the compiler-dev mailing list