[Checkers] AnnotatedTypeMirror is not sufficiently unique

Mahmood Ali mahmood at MIT.EDU
Fri Oct 3 11:17:57 EDT 2008


Mike is correct in his analysis in the earlier email.

> The reason I assumed that AnnotatedTypeMirror was to be unique for  
> each Element is that they have a getElement method. I'm at a loss  
> why there is this method at all if the AnnotatedTypeMirror is just  
> to wrap the TypeMirror and disregard the element property which may  
> be different for "equal" types.
The stored element is not meant to be part of the identity of the type.

Currently, there methods to go from Tree and Element (and visa versa)  
and from both to type.  We found it useful to have a method to go from  
a type to the element generating it, particularly for method and type  
parameter types.  However, getElement() is intentionally left  
undocumented as to when the element is available to discourage using  
it outside the framework until we come up with better plan.

> If I can get a unique AnnotatedTypeMirror for a Tree or Element,  
> then I can create an identity map that maps those to the method  
> receiver in the annotateImplicit methods. This allows me to latter  
> look them up in cases where I only have the AnnotatedTypeMirror (as  
> with the isSubtype method in the BaseTypeChecker).
I would approach this issue a bit differently.  In the Framework, we  
would always represent the context with annotations on the type, so  
other methods are decoupled from the context.  I assume that you may  
able to do this too.

In IGJ for instance, given a field annotated with '@I' and a use  
within a method, '@I' gets resolved to the enclosing method receiver.   
This is done by annotateImplicit in IGJ.  Thus, isSubtype never needs  
to check the context of the field access, as it was abstracted away by  
the inserted annotation.  A similar approach is used for Flow, as the  
context gets abstracted away with Flow adding the appropriate  

Hope this helps,

More information about the checkers mailing list