Fwd: Re: RFR: JEP 359-Records: compiler code

[Vicente Romero]

Hi Joe,

I made an experiment: removing the code you added to PrintingProcessor 
and the tests, TestRecord and family, just work.

Thanks,
Vicente


On 11/5/19 7:13 PM, Joe Darcy wrote:
> Hi Vicente,
>
> On 11/5/2019 2:58 PM, Vicente Romero wrote:
>> Hi Joe,
>>
>> Thanks for the review,
>>
>> On 11/4/19 12:33 AM, Joe Darcy wrote:
>>> Hi Vicente,
>>>
>>> I've taken a pass over the javax.lang.model portions of the change.
>>>
>>> Elements.recordComponentFor should have an @implSpec tag.
>>>
>>> I suggest a double-check of the existing visitors/scanners that used 
>>> to extend one of the "FooVisitor9" types and was updated to extend 
>>> "FooVisitor14". In prior work, I had to add a new method override 
>>> for visitRecordComponent to the printing processor to get the proper 
>>> semantics of that class. For example, PubapiVisitor might need an 
>>> update.
>>
>> I have updated the code for all the comments but the one above. I 
>> don't understand what you are exactly asking for,
>>
> For the printing processor to have the right semantics after record 
> components were modeled with their own top-level element, I had to 
> make the following adjustment:
>
>     http://hg.openjdk.java.net/amber/amber/rev/6b2b5e4c01a7
>
> In effect, the unmodified processor with its default methods, etc. did 
> not "just" work when the superclass was changed from the old JDK-9 
> based visitors to the JDK-14 based one.
>
> Analogous updates may be needed for other visitors/scanners to contend 
> with records and record components.
>
> HTH,
>
> -Joe
>