[GROOVY-7149] @CompileStatic 'Access to <property> is forbidden' with abstract base class and interface

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.3.7
• Fix Version/s: 2.3.8, 2.4.0-beta-4
• Component/s: Static compilation
• Environment: Ubuntu Linux 14.04.1 - 3.13.0-39-generic; Groovy Version: 2.3.7 JVM: 1.8.0_05 Vendor: Oracle Corporation OS: Linux
• Assignee: Cédric Champeau
• Reporter: Matias Bjarland
• Created: 04/Nov/14 05:29
• Updated: 17/Dec/14 13:25
• Resolved: 04/Nov/14 06:33

Description

The CompileStatic annotation incorrectly reports the following error:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
compile_static_failure.groovy: 11: Access to Abstract#name is forbidden @ line 11, column 25.
     println "Y is called $y.name"
                           ^
1 error

when executing the following coce:

import groovy.transform.*

test() 

@CompileStatic
def test() {
  I x = new ConcreteA()
  I y = System.currentTimeMillis() % 2 ? new ConcreteA() : new ConcreteB()

  println "X is called $x.name"
  println "Y is called $y.name"
}

public class ConcreteA extends Abstract { 
  String name
}

public class ConcreteB extends Abstract { 
  String name
}

abstract class Abstract implements I { 
  //abstract String getName()
}

interface I { 
  String getName()
}

The same code (plus a few semicolons) compiles fine in Java and also runs fine without the CompileStatic annotation. I haven't analyzed this very deeply, but this feels like a bug in the CompileStatic implementation.

An interesting note is that for the variable x in the above code, there are no issues when accessing x.name. It seems that the CompileStatic code does type analysis, comes to the conclusion that the concrete type of variable y is either ConcrecteA or ConcreteB, then proceeds to find the largest common deniminator for the two which is abstract class Abstract, and then proceeds to complain about the fact that Abstract does not have method/property 'name'.

Commenting in the commented out 'abstract String getName()' method on class Abstract 'fixes' the error.