[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