barry-m / checker-framework

Automatically exported from code.google.com/p/checker-framework
Other
0 stars 0 forks source link

Unannotated local variable is required to be non-null #416

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
In plume-lib's Lookup program, a warning is issued within the main method:

src/plume/Lookup.java:254: warning: [assignment.type.incompatible] incompatible 
types in assignment.
    EntryReader reader = null;
                         ^
  found   : null
  required: @NonNull @NonRaw EntryReader

However, it should be legal to assign a local variable to null.

To reproduce the problem in a minimized way, unzip the following in the 
plume-lib/java/src/plume/ directory, then run

  make check-nullness-raw

The zip file contains many test cases that fail and one that works.

I have not been able to reproduce the problem outside the context of plume-lib.

Original issue reported on code.google.com by michael.ernst@gmail.com on 19 Mar 2015 at 2:47

Attachments:

GoogleCodeExporter commented 9 years ago
Just to add some detail to this.  The reason this issue occurs is as follows:

1) We fixed a bug that was keeping us from writing annotations into the 
elements of extends/implements clauses.
2) We then started to insert annotations on the extends/implements clauses.
3) AnnotatedTypeFactory.fromMember, when called on FIELDS, PARAMETERS, and 
LOCAL_VARIABLES, calls inheritAnnotationsFromClass, which adds annotations from 
the type representing the declaration of the class to the type currently being 
annotated.
It does so by calling fromElement(classElement) which, because we started 
inserting annotations on the element's extends/implements, now has the default 
annotations in hierarchy.
4) We pull the annotations off the extends/implements clauses and place them on 
the FIELD, PARAMETER, or LOCAL_VARIABLE before the normal.  This happens before 
defaulting so we never apply the defaulting rules.  The extends/implements 
clauses usually have a default of DefaultQualifierInHierarchy, so we 
effectively have 1 default for all of the above locations.

I once again disabled the writing of extends/implements annotations into 
elements.

Original comment by Jonathan...@gmail.com on 19 Mar 2015 at 7:25