[Checkers] infinite loop w/type inference
    Matt Papi 
    mpapi at csail.mit.edu
       
    Wed Mar 19 15:38:39 EDT 2008
    
    
  
The statement
     String s = Collections.emptyList().toString();
causes an infinite loop caused (in part) by type inference. I checked in 
a test case ("GetReceiverLoop" in FrameworkTest); the test file, 
tests/framework/GetRecieverLoop.java, has a comment listing the 
(important) methods involved in the loop.
Note that doing
     String s = Collections.<String>emptyList().toString()
does not cause an infinite loop. It does give a spurious error due a bug 
in (I think) JSR 308 javac, but that's a separate issue and I haven't 
looked into it yet.
It looks like the following is happening:
- inference tries to determine the type of T in the call to emptyList() 
- it looks at the context of the pseudo-assignment, a call to 
toString(), so it asks for the type of the receiver for the toString() 
call (which is the return type of emptyList())
- determining the return type of emptyList() uses inference to determine 
the type of T, etc.
If the assignment context is a method invocation, the code in 
AnnotatedTypes.assignedTo() seems to assume that the tree is an argument 
to that invocation; in the case above, it's the receiver. As a 
workaround, I locally added a check for this (AnnotatedTypes:550 acts as 
a similar check but it isn't reached). Mahmood, if you're busy, I can 
check it in until you get a chance to look at the problem. I'm not 
positive that it's a proper fix, but it doesn't seem to have broken 
anything.
FYI, AnnotatedTypes.getAssignmentContex is misspelled and it's missing 
documentation. Also, is it missing a case for MEMBER_SELECT?
- Matt
    
    
More information about the checkers
mailing list