[GROOVY-8211] ArrayIndexOutOfBoundsException at compilation when accessing a generic type with the wrong number of type parameters

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Fix Version/s: 2.5.0-rc-2
• Component/s: Static compilation
• Assignee: Paul King
• Reporter: M. Justin
• Created: 31/May/17 21:08
• Updated: 26/Jul/18 04:38
• Resolved: 12/Apr/18 17:26

Description

When using @CompileStatic, accessing a method on a type that is specified using too few type parameters causes an ArrayIndexOutOfBoundsException to be thrown by the Groovy compiler. Furthermore, there is no indication where in the code the error occurs, so it can be very difficult to debug the issue.

@CompileStatic
class GenericsCompilation {
  def method() {
    Map<String> map

    map.toString() //This line causes the issue
  }
}

The output is:

$ groovyc GenericsCompilation.groovy 
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during instruction selection: 1

java.lang.ArrayIndexOutOfBoundsException: 1
	at org.codehaus.groovy.ast.tools.GenericsUtils.extractPlaceholders(GenericsUtils.java:164)
	at org.codehaus.groovy.ast.tools.GenericsUtils.extractPlaceholders(GenericsUtils.java:136)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.typeCheckMethodsWithGenerics(StaticTypeCheckingSupport.java:1338)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingSupport.typeCheckMethodsWithGenerics(StaticTypeCheckingSupport.java:1319)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.typeCheckMethodsWithGenericsOrFail(StaticTypeCheckingVisitor.java:4529)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethodCallExpression(StaticTypeCheckingVisitor.java:2966)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethodCallExpression(StaticCompilationVisitor.java:317)
	at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:66)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:71)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitExpressionStatement(ClassCodeVisitorSupport.java:196)
	at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:37)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:166)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitConstructorOrMethod(StaticTypeCheckingVisitor.java:1784)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.startMethodInference(StaticTypeCheckingVisitor.java:2119)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitMethod(StaticTypeCheckingVisitor.java:2078)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitMethod(StaticCompilationVisitor.java:164)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1078)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
	at org.codehaus.groovy.transform.stc.StaticTypeCheckingVisitor.visitClass(StaticTypeCheckingVisitor.java:249)
	at org.codehaus.groovy.transform.sc.StaticCompilationVisitor.visitClass(StaticCompilationVisitor.java:123)
	at org.codehaus.groovy.transform.sc.StaticCompileTransformation.visit(StaticCompileTransformation.java:63)
	at org.codehaus.groovy.transform.ASTTransformationVisitor.visitClass(ASTTransformationVisitor.java:134)
	at org.codehaus.groovy.transform.ASTTransformationVisitor$2.call(ASTTransformationVisitor.java:178)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:525)
	at org.codehaus.groovy.tools.FileSystemCompiler.compile(FileSystemCompiler.java:61)
	at org.codehaus.groovy.tools.FileSystemCompiler.doCompilation(FileSystemCompiler.java:217)
	at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompile(FileSystemCompiler.java:150)
	at org.codehaus.groovy.tools.FileSystemCompiler.commandLineCompileWithErrorHandling(FileSystemCompiler.java:180)
	at org.codehaus.groovy.tools.FileSystemCompiler.main(FileSystemCompiler.java:164)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:109)
	at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:131)

I discovered this issue when doing a refactoring that changed the number of type parameters on a type, but missed updating a spot in the code to use the correct number of parameters. It was completely unclear to me where or what the issue was, other than the fact that it likely had something to do with generics.

Issue Links

• is related to: GROOVY-7865 Better error message in the presence of Generics arity errors