RFR: 8357185: Redundant local variables with unconditionally matching primitive patterns

[Jan Lahoda]

On Wed, 2 Jul 2025 23:06:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> A commit in the implementation of JEP 455, https://github.com/openjdk/jdk/pull/15638/commits/ceee1e4c08457a0793fdfb556db99e057a947af1, added redundant synthetic local variable for trivial `instanceof int`-ish type conversion operations in the javac AST. Such conversions have been present since the introduction of record patterns, and previously they consistently lower to the part before `instanceof`. With this change, the introduced redundant variable is visible in the class file, as seen in the JBS issue.
> 
> Testing: langtools/tools/javac

This seems like a reasonable direction, but please see inline for suggestions for improvements.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2846:

> 2844: 
> 2845:             if (types.isUnconditionallyExact(tree.expr.type, tree.pattern.type)) {
> 2846:                 var = make.Exec(instanceOfExpr);  // drop redundant variable

While this is sufficient to solve the issue, it might be good to go through the if cascade more thoroughly, and only introduce the variable if needed. I.e. in case the value is used more than once. If the value is used only once (like in the `else if (tree.expr.type.isPrimitive()) {`, it ought to be possible to use it directly. Unless there are ordering or other concerns, of course.

test/langtools/tools/javac/patterns/PrimitiveUnconditionallyExactTest.java line 88:

> 86:     public void testExpressionExecution() {
> 87:         int a = 0;
> 88:         boolean b = (a = 5) instanceof int;

I would suggest to also include the same test cases with binding patterns instead of types. In the current state/code shape, there should be no difference, but it would be better to not be caught later if the code shape changes.

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

PR Review: https://git.openjdk.org/jdk/pull/26107#pullrequestreview-2982391708
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182280878
PR Review Comment: https://git.openjdk.org/jdk/pull/26107#discussion_r2182284238