Fix handling of references to methods of array types and type variables #926
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #926 +/- ##
=========================================
Coverage 87.09% 87.09%
- Complexity 1991 1992 +1
=========================================
Files 77 77
Lines 6430 6431 +1
Branches 1245 1246 +1
=========================================
+ Hits 5600 5601 +1
Misses 422 422
Partials 408 408 ☔ View full report in Codecov by Sentry. |
msridhar
changed the title
| @@ -2326,7 +2326,7 @@ private boolean mayBeNullExpr(VisitorState state, ExpressionTree expr) { | |||
| return true; | |||
| case NEW_CLASS: | |||
| case NEW_ARRAY: | |||
| // for string concatenation, auto-boxing | |||
There was a problem hiding this comment.
This was an outdated comment so I deleted it
| || ElementUtils.isTypeElement(baseExpressionSymbol) | ||
| || baseExpressionSymbol.getKind() == ElementKind.TYPE_PARAMETER) { |
There was a problem hiding this comment.
This seems to suggest to me that we were handling cases where the expression is an array type (presumably isTypeElement check), but not the case for type parameters (the second negative test added in this PR). Right?
Makes sense to me either way, but just want to understand this better :)
There was a problem hiding this comment.
Not quite. The isTypeElement method only catches when the element is a class, enum, interface, or annotation type; array types are not handled. That case is handled by the line this PR adds to mayBeNullExpr.
For type variables, the expression itself is just an IdentifierTree. We know it can't be null because it represents a type parameter; that is caught by the check on this line.
After #920 we check the nullability of the qualifier expression of a method reference. We weren't correctly handling the cases where that expression was an array type or a type variable