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

[Jan Lahoda]

On Mon, 7 Nov 2022 09:38:50 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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.

Adding a field here seemed like a reasonable compromise to me. It will make `JCEnhancedForLoop` bigger, but presumably, there won't be that many instances of this class. I'd be more concerned if we were adding a new field to all `JCTree`s, `Symbol`s or `Type`s.

Alternatives would include re-computing the element type in `Flow`, which also feels a bit wasteful, or doing exhaustiveness checks in `Attr`, which is tricky, because exhaustiveness is mostly handled in `Flow`.

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

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