[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 

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