[Checkers] Declarative specification of qualifier hierarchy
mahmood at MIT.EDU
Fri Mar 28 13:41:45 EDT 2008
> I'm not sure I agree with the need for a GraphSubtypeRelation.
I beg to differ. I believe that GraphSubtypeRelation is a necessity,
or at least that all checkers should re-implement their subtype
checking, for the following reasons:
1. We don't have any unifying method for the checkers currently.
Javari is using JavariSubtypeRelation which extends SubtypeRelation
(which is not subclassed by any other class). NonNull and Interned
checkers are using SimpleSubtypeRelation. IGJ is using its own thing
2. SimpleSubtypeRelation cannot really be used for other types. It
uses some hacks to get around issues related to boxing/unboxing and
checking against nullability.
3. SubtypeRelation is horribly broken. It doesn't do anything clever
about boxing/unboxing and doesn't handle type arguments properly. For
example, it doesn't handle the following case (as tested by Javari)
@Mutable List<@Mutable Date> l1 = null;
@Mutable List<@ReadOnly Date> l2 = l1; // should emit error
while l2 is not a subtype of l1.
4. isSubtype sometimes needs to do some more complicated work in
preperation (unbox boxed type / call asSuperOf on lht), and uses
different methods for comparing annotations (subtypes for raw type /
identical for type argument). It will be extra nice to unify them.
5. It seems to me that we will have other types of annotations
relations that aren't a subtype relationship as we have worked on.
Consider the Encrypted/Plaintext type qualifiers that we are
considering as a case example for the CustomChecker. They are not
subtypes of each other, they are indeed in-conflict of each other.
SubtypeRelationship (and SimpleSubtypeRelationship) shouldn't be able
to handle this easily. As a side-note, CustomChecker assumes that the
negative annotation is a supertype of the positive annotation, which
is false ("Plaintext/Encrypted", Trusted/Tained, etc).
More information about the checkers