We ran into this lint bug when switching to 1.3.1: *Unexpected failure during lint analysis of SearchResultsAdapter.java (this is a bug in lint or one of the libraries it depends on) *
TypeSystem.getUnannotatedType(TypeSystem.java:180)->TypeSystem.getParameterizedType(TypeSystem.java:238)->TypeSystem.getParameterizedType(TypeSystem.java:261)->LookupEnvironment.createParameterizedType(LookupEnvironment.java:949) This seems to be the same bug as https://code.google.com/p/android/issues/detail?id=182163 and the older https://code.google.com/p/android/issues/detail?id=172268. The stack trace is similar: *java.lang.ArrayIndexOutOfBoundsException: 806* org.eclipse.jdt.internal.compiler.lookup.TypeSystem.getUnannotatedType(TypeSystem.java:180) org.eclipse.jdt.internal.compiler.lookup.TypeSystem.getParameterizedType(TypeSystem.java:238) org.eclipse.jdt.internal.compiler.lookup.TypeSystem.getParameterizedType(TypeSystem.java:261) org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createParameterizedType(LookupEnvironment.java:949) org.eclipse.jdt.internal.compiler.lookup.Scope$Substitutor.substitute(Scope.java:513) org.eclipse.jdt.internal.compiler.lookup.Scope.substitute(Scope.java:437) org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.superclass(ParameterizedTypeBinding.java:1223) com.android.tools.lint.EcjParser$EcjResolvedClass.getAnnotations(EcjParser.java:1294) com.android.tools.lint.checks.SupportAnnotationDetector$CallVisitor.visitMethodInvocation(SupportAnnotationDetector.java:1371) com.android.tools.lint.client.api.JavaVisitor$DispatchVisitor.visitMethodInvocation(JavaVisitor.java:997) com.android.tools.lint.client.api.JavaVisitor$DelegatingJavaVisitor.visitMethodInvocation(JavaVisitor.java:1365) ... A similar crash was fixed by ignoring the exception in EcjParser.findSuperMethodBinding; however, it looks like the bug can happen when calling into the compiler from multiple places. I looked into the bug and this is what I found: ECJ uses TypeSystem internally to keep track of derived types during compilation. Whenever a new type is derived, the type is given an id and an entry is created in the "types" array; if the type already has an id, the entry is reused. The problem is that the Eclipse compiler resets itself at the end of a compilation (in Compiler.java#534), which resets TypeSystem and invalidates all the existing type ids. Lint needs to derive types on occasion, which will fail whenever the type has a stale id (or worse, pick a wrong type). I suspect that resetting the compiler is desirable in order to release temporary memory, but it obvious causes trouble for lint, which assumes that the compiler is usable once compilation is complete. A simple solution may be to reset all types with id >= TypeIds.T_LastWellKnownTypeId to TypeIds.NoId - I can't tell whether that may cause other issues though! César -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
