RFR: 8262889: Compiler implementation for Record Patterns
Jan Lahoda
jlahoda at openjdk.java.net
Fri May 6 12:01:00 UTC 2022
On Wed, 4 May 2022 10:03:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:
>>
>>> 4178: type = attribTree(tree.var.vartype, env, varInfo);
>>> 4179: } else {
>>> 4180: type = resultInfo.pt;
>>
>> Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).
>
> That said, I'm not sure how this connects with `instanceof`. This patch doesn't seem to alter `visitTypeTest`. In the current code I can see this:
>
> if (tree.pattern.getTag() == BINDINGPATTERN ||
> tree.pattern.getTag() == PARENTHESIZEDPATTERN) {
> attribTree(tree.pattern, env, unknownExprInfo);
> ...
>
>
> This seems wrong for two reasons:
>
> * it doesn't take into account the new pattern tag
> * it uses an "unknown" result info when attributing, meaning that any toplevel `var` pattern will not be attributed correctly
>
> But we seem to have tests covering record patterns and instanceof. so I'm wondering if I'm missing some code update?
Some of the handling inside this ifs is only needed for type test and parenthesized patterns (as record patterns are never unconditional (total)). I have an upcoming patch that should improve the tests here, however.
For `var` - the specification does not allow `var` at the top level (14.30.1, "The LocalVariableType in a top-level type pattern denotes a reference type (and furthermore is not var)."). In my upcoming patch, I am adding a test to ensure meaningful behavior for top-level type test patterns with `var`.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8516
More information about the compiler-dev
mailing list