nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java (2)

105-107: Add documentation for the public getter.

The getInferredLambdaType method is part of the public API but lacks documentation. Consider adding a Javadoc comment explaining:

• When this method returns a non-null value (i.e., for lambda arguments in generic method calls that have undergone inference)
• When it returns null (i.e., for lambdas not part of generic method inference, or before inference has been performed)
• The intended callers and usage context

Example:

+  /**
+   * Returns the inferred type for a lambda expression that was passed as an argument to a generic
+   * method call. The type is computed during constraint-based inference for generic method calls
+   * and includes inferred nullability for type parameters.
+   *
+   * @param tree the lambda expression tree
+   * @return the inferred functional interface type with nullability annotations, or null if the
+   *     lambda was not part of a generic method call requiring inference
+   */
   public @Nullable Type getInferredLambdaType(LambdaExpressionTree tree) {

---

983-992: Consider adding a comment to explain lambda fallback behavior.

The code correctly uses cached inferred types for lambda arguments, but the fallback behavior when a lambda is not in the cache (i.e., actualParameterType remains null and checks are skipped at line 993) is subtle. This is actually correct because:

1. getTreeType would return the functional interface type, which isn't useful for checking type parameter nullability
2. Only generic method calls populate the cache through inference
3. For non-generic methods, there are no type parameters to infer/check anyway

However, this reasoning is not obvious from the code. Consider adding a comment explaining why lambdas not in the cache are skipped rather than falling back to getTreeType.

   Type actualParameterType = null;
   if ((currentActualParam instanceof LambdaExpressionTree)) {
+    // For lambda arguments, use the inferred type from the constraint solver if available.
+    // If not in cache (e.g., non-generic method calls), actualParameterType remains null
+    // and checks are skipped below, which is correct since getTreeType() would only return
+    // the functional interface type, not the lambda's actual return type.
     Type lambdaInferredType = inferredLambdaTypes.get(currentActualParam);

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: msridhar
PR: uber/NullAway#1248
File: nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java:847-857
Timestamp: 2025-08-28T04:54:20.953Z
Learning: In NullAway's GenericsChecks.java, NewClassTree support for explicit type argument substitution requires more extensive changes beyond just modifying the conditional in compareGenericTypeParameterNullabilityForCall. The maintainers prefer to handle NewClassTree support in a separate follow-up rather than expanding the scope of PRs focused on specific issues like super constructor calls.

Learnt from: msridhar
PR: uber/NullAway#1248
File: nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java:847-857
Timestamp: 2025-08-28T04:54:20.953Z
Learning: In NullAway's GenericsChecks.java, NewClassTree support for explicit type argument substitution requires more extensive changes beyond just modifying the conditional in compareGenericTypeParameterNullabilityForCall. The maintainers prefer to handle NewClassTree support in a separate follow-up rather than expanding the scope of PRs focused on specific issues like super constructor calls.

nullaway/src/test/java/com/uber/nullaway/jspecify/GenericMethodTests.java (1)

1249-1274: Good coverage for lambda-argument inference; matches prior ask.

ret3/ret4 were added and ret2 asserts the deref error as intended. Looks solid.

nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java (1)

988-997: Fallback to AST type when no inferred lambda type available.

Prevents silently skipping param checks for non-generic or failed-inference cases.

Apply:

-              Type actualParameterType = null;
-              if ((currentActualParam instanceof LambdaExpressionTree)) {
-                Type lambdaInferredType = inferredLambdaTypes.get(currentActualParam);
-                if (lambdaInferredType != null) {
-                  actualParameterType = lambdaInferredType;
-                }
-              } else {
-                actualParameterType = getTreeType(currentActualParam, state);
-              }
+              Type actualParameterType;
+              if (currentActualParam instanceof LambdaExpressionTree) {
+                Type lambdaInferredType = inferredLambdaTypes.get(currentActualParam);
+                actualParameterType =
+                    (lambdaInferredType != null)
+                        ? lambdaInferredType
+                        : getTreeType(currentActualParam, state);
+              } else {
+                actualParameterType = getTreeType(currentActualParam, state);
+              }

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: msridhar
PR: uber/NullAway#1248
File: nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java:847-857
Timestamp: 2025-08-28T04:54:20.953Z
Learning: In NullAway's GenericsChecks.java, NewClassTree support for explicit type argument substitution requires more extensive changes beyond just modifying the conditional in compareGenericTypeParameterNullabilityForCall. The maintainers prefer to handle NewClassTree support in a separate follow-up rather than expanding the scope of PRs focused on specific issues like super constructor calls.

Learnt from: msridhar
PR: uber/NullAway#1248
File: nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java:847-857
Timestamp: 2025-08-28T04:54:20.953Z
Learning: In NullAway's GenericsChecks.java, NewClassTree support for explicit type argument substitution requires more extensive changes beyond just modifying the conditional in compareGenericTypeParameterNullabilityForCall. The maintainers prefer to handle NewClassTree support in a separate follow-up rather than expanding the scope of PRs focused on specific issues like super constructor calls.