RFR: JDK-8252307: javac rejects code with annotation applicable to fields
Joe Darcy
joe.darcy at oracle.com
Fri Sep 4 16:56:23 UTC 2020
Looks okay; cheers,
-Joe
On 9/3/2020 9:12 AM, Vicente Romero wrote:
> ping, I would like to push this one before the github transition,
>
> Thanks,
> Vicente
>
> On 9/2/20 2:10 PM, Vicente Romero wrote:
>> ping
>>
>> On 9/1/20 11:51 AM, Vicente Romero wrote:
>>> ping
>>>
>>> On 8/31/20 1:10 PM, Vicente Romero wrote:
>>>> Hi,
>>>>
>>>> Please review fix for [1] at [2]. There were several issues at play
>>>> here. First the parameters added by the compiler to the compact
>>>> constructor were not marked as generated, meaning that later on
>>>> when checking for annotations, at Check::validateAnnotation, it
>>>> couldn't be determine if the annotations were added automatically
>>>> with the intention to remove them if out of place. Which is the
>>>> strategy for elements generated from the record components. Or if
>>>> they were explicitly added by the user. The current implementation
>>>> was assuming the last option and thus flagging an error. Also I
>>>> realized that at Check::getApplicableTargets, the case when the
>>>> target is MODULE was not covered. This was not the product of the
>>>> records patch which rewrote this method, this was like this since
>>>> the modules times. I think that for completeness, and correctness,
>>>> there should be a case for target MODULE at
>>>> Check::getApplicableTargets. The compiler was accepting annotations
>>>> applied to ElementType.MODULE, just because it was accepting
>>>> annotations applied to unknown targets assuming that there was a
>>>> bug in the source that would be flagged anyway. I realize that this
>>>> change to Check::getApplicableTargets could be considered outside
>>>> of the reach of this patch so I'm OK with removing it and file a
>>>> separate bug if we consider it a better approach,
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252307
>>>> [2] http://cr.openjdk.java.net/~vromero/8252307/webrev.00/
>>>
>>
>
More information about the compiler-dev
mailing list