RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v4]

[Aggelos Biboudis]

On Fri, 28 Apr 2023 09:07:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test files with JDK 8307007 bug id
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777:
> 
>> 1775:                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
>> 1776:                             }
>> 1777:                         } else if (guard != null) {
> 
> I guess this is caused by something like:
> 
> case _ when ...
> 
> If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't.

Actually this is for the case where we have `case A(_), B(C _) when ... `. In that case we are sure that the only scope we can use is the switch environment (since no bindings are introduced). Hm, I don't see another way of refactoring this without depending on `labels.tail.isEmpty()`

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826:
> 
>> 824:                 //type test pattern:
>> 825:                 UnnamedDetails result = identOrFlagUnderscore(mods);
>> 826:                 JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null));
> 
> Do you think we can delegate to `variableDeclarator` here?

The behavior I observe is that `variableDeclarator` does not behave well when we have a `var` instead of a type in a type pattern. `variableDeclarator` is well suited for variable declarations but not for type patterns. But I can investigate further.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181938984
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1181938402