[JSR308] Constructor Annotation Inference

[Mahmood Ali]

Greetings Niko,

It's great to hear back from you and your continuous work on the  
checker framework.

Before answering your email, I would like to mention a convention used  
within AnnotatedTypeFactory.  Many methods in the class follow a  
naming convention: .fromFOO methods (e.g. fromTree, fromExpression)  
return types with only the annotations that the user explicitly  
inserted; .getAnnotatedType* methods (e.g. getAnnotatedType,  
getAnnotatedTypeFromTypeTree) return types with the annotations  
enforced in such trees whether explicitly inserted by the user or  
implicitly inserted by the checker.

With this naming convention in mind, AnnotatedTypeFactory.fromFOO  
methods aren't designed to be overriden, hence your difficulty.  In  
the case of new class trees, only the annotations inserted by the user  
(as the tree is annotatable) should be returned in fromExpression.

If you want to insert implicit annotations to that type, you can  
override .annotateImplicit().  The method is called by  
getAnnotatedType().

I am not quite sure if this is sufficient for you.  Worst case  
scenario is that you simply override .fromExpression itself.

> I had expected that fromExpression() would eventually invoke
> constructorFromUse() to get the correct constructor signature, and use
> that to compute the resulting type of the NewClassTree, but I see that
> is not the case.  Moreover, thinking about it more, I'm not sure if
> that makes sense anyhow-- as it happens, in my case the receiver in
> the constructor's executable type is the same as the result from the
> NewClassTree, but I suppose that is not necessarily the case.
In the checkers we have used so far, the receiver of a constructor  
isn't necessarily the type of the new class expression tree.  For  
example, the constructor receiver is RAW according to the nullness  
checker, yet all new class trees are of type NonNull.

If you can come up with a generalized proposal on how handle  
constructorFromUse(), we'll be happy to adopt it.

> Looking at
> the code, I see no obvious hook apart from overloading
> fromExpression() altogether.
Yes.  As discussed earlier, fromExpression() wasn't designed to be  
overriden.

> As a side comment: [use factory method design pattern for visit  
> creation]
The suggested pattern is used in BasicAnnotatedTypeFactory which is  
designed for extension.

As a quick note, the main reason for not designing the static visitors  
in AnnotatedTypeFactory to be subclassed, as that they were meant to  
be an internal implementation and we desire to change it without  
making a commitment of maintenance.  We can work on providing a better  
interface for you to override.

Hope that helps.

Regards,
Mahmood