[Checkers] Problems with NonNull checker

[Michael Ernst]

Matt-

Thanks for the quick action on these bugs.

> >   * Error messages for class names, when accessing a static variable -- the
> >    message says that the class name is possibly-null.  This is most of the
> >    messages, in fact.
> 
> While I don't yet know what's wrong here, I noticed that when running
> the checker on a single file (and using -sourcepath so javac can find
> the rest), these errors do not occur (and there are test cases for it
> that don't fail). I'm looking into it now.

Yes, this was exactly my experience as well.  So I was unable to give you a
test case.

> (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?

> >  >   * Error messages for class names, when accessing a static variable -- the
> >  >    message says that the class name is possibly-null.  This is most of the
> >  >    messages, in fact.
> 
> It seems that this was caused by (bad) copies of the qualifier
> declarations in Daikon's source without meta-annotations (particularly
> @TypeQualifier; the framework rejects anything without that so as to
> exclude @Deprecated and others from appearing on types).
> 
> 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.

mernst-vmu 18% javac `findfile '*.java'`
./daikon/FileIO.java:207: cannot find symbol
symbol  : class Raw
location: class daikon.FileIO.ParentRelation
    public String toString() /*@Raw*/  { return parent_ppt_name + "[" + id + "] "
                                ^
Note: ./daikon/LogHelper.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error


The reason that the checkers directory is in Daikon at all is because of
the "import checkers.quals.*;" or "import checkers.quals.Interned;"
statement at the top of many files.  Compiling Daikon with an ordinary Java
compiler fails if the ordinary compiler can't find that package, so the
package has to be in the Daikon codebase.

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.)

                    -Mike