RFR: 8294943: Implement record patterns in enhanced for [v5]

Aggelos Biboudis abimpoudis at openjdk.org
Mon Nov 7 09:42:37 UTC 2022


On Sun, 6 Nov 2022 19:26:05 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Simplify getDeclarationKind
>>  - Adjustments to make for-patterns and JDK-8294942 work together.
>>  - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
>>  - Address Review
>>  - Fix applicability bug
>>  - Store element type calculation result in JCEnhancedForLoop
>>  - API cleanup.
>>  - Adding @since, adding PreviewFeature, restoring API method.
>>  - 8294943: Implement record patterns in enhanced for
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 1216:
> 
>> 1214:         public JCExpression expr;
>> 1215:         public JCStatement body;
>> 1216:         public Type elementType;
> 
> is this new field strictly necessary? usually we try not to add new fields to ASTs unless we don't have any other option as they will imply more memory consumption.

We would need to discover again the type of the element in `AliveAnalyzer` when we need to do the exhaustivity check. This avoids an extra refactoring to extract code that discovers this type from attribution. If there is another way to persist the type between phases, I am open to remove it.

-------------

PR: https://git.openjdk.org/jdk/pull/10798


More information about the compiler-dev mailing list