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

[Maurizio Cimadamore]

On Mon, 7 Nov 2022 09:49:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

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

We also capture fields like these in other cases; e.g. varargs method calls have their `elementType` set, and functional expressions (like lambdas) have their target type set in the same way. So I think this is good.

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

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