Field and array type resolution differs between reads and assignment targets
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
Research direction
Start in nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java and compare getAssignedVariableType with getTreeType, focusing on how each restores field annotations for identifiers, member selects, array accesses and assignment expressions. Read the review discussion in #2069 first, since it records the behavior change the author accepted. Done means reads and assignment targets share one field-type resolver without recursion, with regression tests covering inherited annotations and generic receivers, and raw types, captures and dataflow fallbacks still pass.
Written by the indexing model from the issue text.
Description
When checking reads and writes of generic fields and array elements, NullAway should resolve inherited nullness annotations and receiver substitutions consistently. The review of #2069 identified separate type-resolution paths that can disagree; consolidating them was deferred because it can change field-read behavior.
Follow-up to the review discussion in #2069. The author confirmed the behavior-change concern, and the reviewer requested a follow-up issue.
Context
In nullaway/src/main/java/com/uber/nullaway/generics/GenericsChecks.java, getAssignedVariableType overlaps with getTreeType in resolving identifiers, member selects, array accesses, and assignment expressions. The assignment-target path restores annotations from a field as a member of its receiver type, whereas getTreeType's member-select path restores annotations from the field's declared type.
This is a maintenance follow-up to #2069, rather than a newly reproduced release bug. The scope is the resolution difference identified in that review.
Proposed work
Share field and array location-type resolution between reads, assignment targets, and inference contexts. One possible approach is a common field-type resolver parameterized by calledFromDataflow, with ValueTarget adding the declaration contract around the resolved type. The implementation can choose a different structure.
Preserve raw-type handling, javac capture identity, and existing fallback behavior. Avoid introducing recursion between getTreeType and the assignment-target resolver. Treat changes to read behavior as deliberate semantic changes, with regression coverage, rather than assuming this is a mechanical extraction.
Acceptance criteria
- Reads and assignment targets resolve a field as a member of its receiver type through shared logic, preserving inherited annotations and receiver substitutions.
- Array-element and assignment-expression resolution reuse the applicable shared logic.
- Regression tests cover the read/write resolution difference and pin down any changed diagnostics, including cases involving inherited annotations and generic receivers.
- Raw types, wildcard captures, dataflow calls, and fallback paths retain their required behavior without recursive resolution.
Broader changes to generic inference are outside this follow-up.
Related issue
#1854 tracks a specific false negative when reading a generic field through a ? super receiver. This follow-up tracks consolidation of the resolution paths; any effect on that bug should be checked explicitly.
Duplicate searches across open and closed issues: repo:uber/NullAway is:issue "getAssignedVariableType", repo:uber/NullAway is:issue "getTreeType", and repo:uber/NullAway is:issue "2069". No existing consolidation issue was found.
- Dominant language
- Java
- Stars
- 4.1k
- Forks
- 379
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 106
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from uber/NullAway
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
uber/NullAway#2145 · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
uber/NullAway#2058 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
uber/NullAway#1899 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 15/100
uber/NullAway#2160 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 62/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
johanhaleby/occurrent#1505 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
FasterXML/jackson-databind#6443 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
finos/fluxnova-bpm-platform#387 ·
Maintainers usually reply within 4 days
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100