Field and array type resolution differs between reads and assignment targets

Aperta
  • Qualcosa non va?
#2,155 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
tooling

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
4.1k
Fork
381
Merge medio
1g 2h
PR unite (30g)
106

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di uber/NullAway

Tutte le issue di uber/NullAway

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.