[JSR308] Creating new annotated types.

[Niko Matsakis]

>> That said, in most cases it is not necessary
>> to manipulate the AnnotatedTypeMirrors-- except when it is.
> Can you provide cases when it is necessary to manipulate  
> AnnotatedTypeMirror?

Well, one example that comes to mind is mapping the annotations on a  
type that you receive as input.  Right now, the only way I know of to  
do that is destructively (i.e., mutate the annotated type mirror in  
place).  You can use getCopy() to make a shallow copy, but when you  
have a compound type such as a DeclaredType or an ExecutableType that  
does not allow you to map annotations on the subtypes, such as type  
arguments.  A deep clone operation solves this problem.

I run into this in my code fairly frequently, as my annotations are  
more like type arguments than the binary present/absent annotations  
that the checkers framework is designed for.  In other words, types in  
my system have exactly one annotation, which is deserialized into a  
structured set of region and effect parameters.  I sometimes need to  
apply mappings to these annotations which can affect not only the type  
at hand but also its type arguments.

One example where this comes up is in the isSubtype() function.  In  
this case, I have two type mirrors as input and I would like to do  
some implicit inference in the future that might require remapping the  
annotations as part of the subtype test.  Right now I would simply not  
be able to do this.

I already listed the example of wanting to synthesize the type of a  
"special" function whose type relationship is not readily described  
with Java generics (though presumably its erasure IS describable).   
Since the erasure of the types is the same, this is really the same  
mapping problem described above.  As you pointed out, in this  
particular case, it may be possible to work around this in  
annotateImplicit(), precisely because you know in that case that the  
input type is safe to mutate.  I don't think that's always the case,  
though.

Off hand, I can't think of a specific case where the added flexibility  
I put into the AnnotatedTypeCloner class is necessary.  However, I  
also don't see how it's dangerous.  As I said, I'd be more worried  
about having insufficient flexibility than too much.

I am of course nowhere near as familiar with the framework as you are,  
so it might be that I am going about things the wrong way.   Let me  
know what you think.


regards,
Niko