[Checkers] AnnotatedTypeFactory.getSelfType

Mahmood Ali mahmood at MIT.EDU
Tue Aug 12 04:45:40 EDT 2008


Hi Artemus,

I just wanted to point out that I just made the 0.7.6 release that  
includes a fix for bugs related to inner classes referencing outer  
classes.  Methods of interest would be:
   AnnotatedTypeFactory.getImplicitReceiverType(Tree)
   AnnotatedTypeFactory.getEnclosingType(TypeElement, Tree)

They are undocumented now,; I would like to test them further and  
document them once I have a clearer idea of they are supposed to do.   
(Errr... this is a very bad practice).

Regards,
Mahmood

On Aug 9, 2008, at 4:35 PM, Artemus Harper wrote:

> If I understand this correctly there will be a hook to annotate the  
> "self type" of enclosing classes?
>
> E.g.
> public class Foo
> {
>    public void method()
>    {
>       Object o = new Object() {
>            public void method2()
>            {
>               method3(); //line A
>               method4(); //line B
>               Foo.this.method4(); //line C
>            }
>            public void method3() { }
>        };
>    }
>    public void method4() { }
> }
>
> Will I be able to annotate the receiver on line A differently from  
> the receiver on line B or line C?
>
> Or will there just be a way to annotate the invisible outer class  
> instance that each non-static inner class has?
>
> Here is a piece of my test code that I am property trying to check:
>
>     //Returns an Iterable that can be used in a foreach loop, as  
> each element is given
>     //in the loop it is removed from the array (in reverse order).  
> The receiver for this
>     //is not NoEscape since the return value indirectly references  
> this instance.
>     @InnerUnique({"T->T"})
>     public Iterable<T> drainToItr()
>     {
>         return new @InnerUnique({"T->T"}) Iterable<T>()
>         {
>             @InnerUnique({"T->E"})
>             public Iterator<T> iterator() @InnerUnique({"?T"})
>             {
>                 return new @InnerUnique({"T<-E"}) Iterator<T>()
>                 {
>                     @Override
>                     @Unique({"T"})
>                     public T next()
>                     {
>                         return removeLast();
>                     }
>
>                     @Override
>                     public boolean hasNext()
>                     {
>                         return size() > 0;
>                     }
>
>                     @Override
>                     public void remove()
>                     {
>                         //Each element is removed even when remove()  
> is not called.
>                     }
>                 };
>             }
>         };
>     }
>
> In this case the removeLast() method refers to a method 2 levels up.
> On Sat, Aug 9, 2008 at 1:04 PM, Mahmood Ali <mahmood at mit.edu> wrote:
> Hi Artemus,
>
> Thank you for reporting the bug.  The framework doesn't anything  
> clever with enclosed types yet, but should.
>
> I think that the proper solution would be to have getReceiver use  
> another method that handles trees like EnclosingClass.this.foo.
>
> I will add it to my TODO list and it should be fixed hopefully soon.
>
> Regards,
> Mahmood
>
>
> On Aug 7, 2008, at 9:54 PM, Artemus Harper wrote:
>
> Is this method (when it gets fixed) going to be responsible for  
> determining which self type an expression refers to in the case of  
> inner classes referring to outer class methods or fields?
>
> getReceiver depends on this method and its not giving me the correct  
> results for inner classes, and I am planning to hack getSelfType to  
> determine the correct receiver to return. I want to know if this  
> will cause incompadibilities with future code.
> -- 
> Artemus Harper
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>
>
>
>
> -- 
> Artemus Harper

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/mailman/private/checkers/attachments/20080812/626c5cb2/attachment.htm 


More information about the checkers mailing list