[Checkers] Declarative specification of qualifier hierarchy

[Telmo]

Yes, all checkers need to implement their own type checking.
SimpleSubtypeRelation is not expressive enough for anything other than a 
simple subtype relationship.

I do think extending a Relation class for each checker is better than 
expressing the hierarchy through meta-annotations. A class that extends 
SubtypeRelation doesn't need to express only subtype relationships per se;
as JavariSubtypeRelation uses it, it is just an abstract class from which 
the relationship between annotations can be expressed. Encrypted/Plaintext 
type qualifiers could be distinguished by a EPSubtypeRelation with the 
appropriate isSubtype method that doesn't invoke the super method.

(Perhaps SubtypeRelation could be refactored with a new name, 
TypeRelation, to clarify that it can do more than just specify a boolean 
relation between annotations; it can express a boolean relation between 
annotated types.)

To put it in other way, the differences between the desired functionality 
of SubtypeRelation and GraphSubtypeRelation are still not clear to me; and 
I think each checker could express its allowed assignments by extending 
some subclass of SubtypeRelation (including SubtypeRelation).

-Telmo


On Fri, 28 Mar 2008, Mahmood Ali wrote:

>> 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 within Checker.
>
> 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).
>
> - Mahmood
>
>