[Checkers] Problems with NonNull checker

[Matt Papi]

Mike,

>  > (Also, it seems like the long delay is caused mainly by checking
>  > "FunctionBinary.java", which is ~17k lines. You can use "-Afilenames"
>  > to see which files are being checked.)
>
>  That is long, but it doesn't take very long to compile.  Is there some
>  remaining inefficiency in the checker?

There could very well be. However, I don't expect the NonNull checker
to be as fast as, say, the Interned checker; NonNull calls into the
factory for every member select (compare to Interned, which does so
only for != and ==, and IGJ, which has an empty visitor). NonNull also
uses flow-sensitive inference, and customizes it to do a bit of extra
checking (for "!= null" checks). It does seem like it's slower than it
should be, but not so slow as to be alarming at this point.


>  > Deleting the entire "checkers" directory made these errors go away. I
>  > haven't tried updating the qualifier definitions --  that might work,
>  > though you'd probably have to copy checkers.metaquals as well.
>
>  I think I'm using the latest version of the qualifiers annotations; there
>  is no diff between the Daikon and checkers versions of checkers.quals.
>  In case it helps, this is the specific error message that I am seeing; I
>  only have to change that one instance.

Sorry if I was unclear -- deleting "checkers" only fixed the static
dereference issue for me; the @Raw issue remains. In fact, I tried
replacing @Raw with @NonNull, and I get "cannot find symbol" for
NonNull as well (and for this reason I suspect that it's a compiler
bug).

I'm not seeing differences in the qualifiers in Daikon CVS, but
~mernst/tmp/nninfer/invariants-java/checkers/quals has old
definitions. In particular, the declaration is lacking the
@TypeQualifier meta-annotation, which causes the framework to reject
(both implicit and explicit) attempts to add NonNull to a type.


>  If we could comment this out or use some other mechanism, then I wouldn't
>  have to have a copy of the qualifiers in Daikon.  (This is the mechanism
>  that Mahmood was asking about recently.)

I started working on this a while back and got sidetracked; I'll see
what state the code is in. Personally, though, I think this is a
slippery slope. Annotations in comments give us backward
compatibility, enabling us to compile code in Java 5/6. Optional
imports have nothing to do with backward compatibility at all, and I
could imagine this confusing users that have legitimately commented
imports (rare as they may be).

- Matt