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