RFR: JEP 359-Records: compiler code

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Nov 12 08:42:33 UTC 2019


The compiler changes look good - I still see indentiation issues in 
TypeEnter, especially in lines 1225-1238.

Also, in JavacParser:

* in  blockStatements we do this:

  if (isRecordStart() && allowRecords) {
2629             dc = token.comment(CommentStyle.JAVADOC);
2630             return 
List.of(recordDeclaration(F.at(pos).Modifiers(0), dc));

But isRecordStart() can generate diagnostics - so should it be better to 
invert the condition, as in:

if (allowRecords && isRecordStart()) - to avoid spurious preview 
warnings on source < 14?

* how does this code avoids the problem described well by Jan in a 
previous email in this thread - reporting below:

> I think I was touching that in one of my comments. I am afraid it is 
> probably not so simple - we could do the checks easily for top-level 
> records, but not so easily for nested records. I.e.:
> ---
> class X {
>     record R(int i) {
>         return null;
>     }
> }
> class record {}
> ---
>
> is valid currently ("R" is a method which returns "record"), but not 
> with the patch:
> ---
> $ javac /tmp/R.java
> /tmp/R.java:2: error: records are a preview feature and are disabled 
> by default.
> record R(int i) {
> ^
>   (use --enable-preview to enable records)
> /tmp/R.java:3: error: illegal start of type
> return null; 

Seems to me that we are using isRecordStarts in a member position - 
meaning that a member record would be parsed even if it's just a method 
returning a 'record' type (which is allowed, with warning).

Maybe gate the isRecordStart with allowRecords? Actually, maybe we 
should add  ' && allowRecords' check inside isRecordStart() all the 
time, to make sure we don't pick up more records than intended?

Maurizio


On 12/11/2019 00:31, Vicente Romero wrote:
> Hi all,
>
> I have uploaded another iteration to [3]. This iteration fixes a 
> regression introduced with one of the fixes that were addressing 
> preview review comments. In short this is the most important change:
>
> diff -r 5d6410bfafe0 -r 806e05ae98e3 
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> --- 
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java 
> Sun Nov 10 19:41:49 2019 +0000
> +++ 
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java 
> Mon Nov 11 23:42:59 2019 +0000
> @@ -1217,8 +1217,11 @@
>                  if (sym.owner.owner.kind == PCK ||
>                      (sym.owner.flags_field & STATIC) != 0)
>                      mask |= STATIC;
> -                else if ((flags & ENUM) != 0)
> +                else if ((flags & ENUM) != 0) {
>                      log.error(pos, Errors.EnumsMustBeStatic);
> +                } else if ((flags & RECORD) != 0) {
> +                    log.error(pos, 
> Errors.RecordDeclarationNotAllowedInInnerClasses);
> +                }
>                  // Nested interfaces and enums are always STATIC 
> (Spec ???)
>                  if ((flags & (INTERFACE | ENUM | RECORD)) != 0 ) 
> implicit = STATIC;
>              } else {
>
> The regression introduced was that code like:
>
> class Outer {
>     class Inner {
>         record R() {}
>     }
> }
>
> started being accepted by the compiler. The reason is because the code 
> that checks for static declarations inside inner classes in the 
> compiler, checks for declared modifiers, but records are `implicitly` 
> static as enums are. For this reason I'm now doing the check for 
> records inside inner classes in the same place where a similar check 
> for enums is done at Check::checkFlags. I also introduced a new error 
> message, please see it inserted into the webrev.
>
> Thanks,
> Vicente
>
> [3] http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.06
>
> On 11/10/19 6:48 AM, Vicente Romero wrote:
>> Hi,
>>
>> I have uploaded another iteration to [2]. This one includes some 
>> missing type and annotation javax.lang.model visitors,
>>
>> Thanks,
>> Vicente
>>
>> [2] 
>> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.05
>>
>> On 11/8/19 5:02 PM, Vicente Romero wrote:
>>> Hi all,
>>>
>>> Please review another iteration of the compiler implementation for 
>>> records at [1]. New in this iteration:
>>>
>>> - I added an @implSpec comment to method: 
>>> javax.lang.model.util.Elements::recordComponentFor
>>> - moved the list of forbidden record component names to class Names
>>> - added the code proposed by Maurizio to the parser with a small 
>>> tweak for records declared as members
>>> - modified the error message to indicate that any non-canonical 
>>> constructor should invoke another constructor to: "constructor is 
>>> not canonical, so its first statement must invoke another constructor"
>>> - added method: 
>>> com.sun.tools.sjavac.comp.PubapiVisitor::visitRecordComponent
>>> - added new visitor: javax.lang.model.util.AbstractTypeVisitor14
>>> - moved annotation processing tests for records to common place for 
>>> other annotation processing tests
>>>
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] 
>>> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.04
>>
>


More information about the amber-dev mailing list