Fix NPE in VarWithPrimitive when lambda parameters have inferred primitive types

[HarshMehta112]

Problem

Fixes #5857

VarWithPrimitive throws a NullPointerException when a lambda has an implicit
parameter whose inferred type is a primitive:

byte[] bar = new byte[6];
Map<Byte, List<Byte>> indicesMap =
    IntStream.range(0, 6)
        .mapToObj(n -> n)
        .collect(Collectors.groupingBy(
            n -> bar[n],
            Collectors.mapping(
                n -> (byte) n.intValue(),
                Collectors.toList())));

// Exception:
java.lang.NullPointerException: Cannot invoke
"com.sun.tools.javac.tree.JCTree.getStartPosition()"
because "tree" is null

Root Cause

hasImplicitType() returns true for both:

• var declarations
• Implicit lambda parameters (when VariableTree.getType() is null, per JDK-8268850)

VarWithPrimitive used hasImplicitType() as its guard, so lambda parameters
with inferred primitive types passed the check and reached
replaceVariableType().

Inside replaceVariableType(), tree.getType() returns null for these
parameters. hasExplicitSource(null, state) was then called unconditionally,
which invokes:

getStartPosition(null)

resulting in a NullPointerException.

Fix

Add a null guard for type in SuggestedFixes.replaceVariableType() at the
actual crash site.

If type == null:

• Skip the hasExplicitSource() call.
• Fall through to getStartPosition(tree).

The subsequent token scan finds no var keyword for implicit lambda
parameters and correctly returns Optional.empty(), producing NO_MATCH
without throwing an exception.

This is the minimal fix because:

• It addresses the actual crash site.
• It is defensive against any other callers that may pass a VariableTree
  with a null type.

Tests

implicitLambdaParameter_noMatch

Regression test reproducing the exact code from the bug report:

• Single-parameter lambdas
• Inferred int and byte types
• Verifies NO_MATCH and no exception

multiParamImplicitLambda_noMatch

Tests a multi-parameter implicit lambda:

IntBinaryOperator op = (a, b) -> a + b;

• Both parameters inferred as int
• Verifies NO_MATCH and no exception

explicitLambdaParam_noMatch

Tests an explicit lambda parameter:

(int n) -> n

• hasImplicitType() returns false
• Verifies no match is reported

enhancedForLoop

Tests:

for (var x : intArray) {
    // ...
}

Expected fix:

for (int x : intArray) {
    // ...
}

forLoopInitializer

Tests:

for (var i = 0; i < 10; i++) {
    // ...
}

Expected fix:

for (int i = 0; i < 10; i++) {
    // ...
}

[cushon]

Thanks for the fix!

Could you also add a couple more test cases:

• a lambda that has a var parameter like IntUnaryOperator op = (var n) -> n * 2;
• with an annotation like @interface A { int var() default 0; } on the lambda parameter IntUnaryOperator op = (@A(var = 0) var n) -> n * 2;, to make sure the replacement doesn't replace the occurrence of var in the annotation instead of the type
• a local variable test with @A(var = 0) var n also

[cushon]

It looks like the author information for the commits are from two different github accounts and emails, and there is only a CLA on file for one of them

Can you sign the CLA for the other account or update the author information for the commits if it is incorrect?

[cushon]

The CI shows this test fails on JDK 27 because there's now an AST node for the var type, so the replacement succeeds

Can you split this test into separate tests for JDK < 27 and JDK >= 27, and use assume().that(Runtime.version().feature()).{isAtLeast,isLessThan}(27) to run the tests on the different JDK versions?

[HarshMehta112]

Done — I split the test into JDK < 27 and JDK ≥ 27 variants using assume().that(Runtime.version().feature()).isLessThan(27) and isAtLeast(27).