Fwd: Re: RFR: JEP 359-Records: compiler code
vicente.romero at oracle.com
Wed Nov 6 13:11:26 UTC 2019
I made an experiment: removing the code you added to PrintingProcessor
and the tests, TestRecord and family, just work.
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
>> 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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev