[Checkers] @ImplicitFor meta-annotation

[Matt Papi]

[Sorry about the delay - I spent the last few days working on the ABB
talk and catching up on classwork and fell behind on email.]

>  What is the more complex design that shortens the checkers even more?  (Is
>  it worth implementing, or not?)

I was thinking about being able to specify a set of (pre-defined)
conditions, such as "non-static receivers" (as in NonNull). It might
be worth exploring in the future, but for now I don't think so for
now.

>  I have one concern with the location of the meta-annotation on the
>  @interface declaration.  This means that in order to understand the type
>  factory, a programmer must read both the @interface declaration and also
>  the type factory implementation.  The information is not all in one place.

That's true, and certainly a good point. On the other hand, writing
@ImplicitFor on an annotation describes (in part) what an annotation
*is*; writing it on the factory would describe (in part) what the
factory *does*, which I feel violates the idea behind
meta-annotations. Also, a programmer should probably read the
@interface declaration anyway, for javadoc and type hierarchy
meta-annotations.

I don't feel _that_ strongly about this, though, and it's very easy to
change the implementation to go one way or the other.


>  there are two issues now
>  1. how does implicitfor overlap with default.  in igj for example,
> placeholder is implicit in constructors only when no qualifier is found.
> can we have implicitfor[all] default for everything if there is no other
> default

In the implementation, I created an abstract TypeAnnotator and
TreeAnnotator that read the @ImplicitFor annotations and apply them,
so for now, @ImplicitFor is only read by TreePreAnnotator and
TypePostAnnotator (so its only effect at present is to make those
classes smaller). @ImplicitFor could (and probably should) also be
utilized in other places like the @Default mechanism and the base
implementation of annotateImplicit. An @ImplicitFor(ALL) is a good
idea, and it would certainly be possible.

>  2. now that we have annotationsrelations, we should propagate it to the
> factory which can utilize to to check within an annotation exists or not.
> similarly for implicitfromclass.

Currently, AnnotatedTypeMirror.addAnnotation rejects any annotation
that is not a @TypeQualifier. We could also have that method reject
annotations that are incompatible. This approach would allow you to,
say, throw an exception so that you could see in the stack trace
exactly what code is trying to add the offending annotation. Doing it
in the factory works, but might make it harder to figure out what code
added the offending annotation.

- Matt