Scott Murphy Heiberg created GROOVY-12612:
---------------------------------------------
Summary: Explicit this.m() inside a closure or lambda in a trait
method is called on the trait helper class instead of the implementing instance
Key: GROOVY-12612
URL: https://issues.apache.org/jira/browse/GROOVY-12612
Project: Groovy
Issue Type: Bug
Affects Versions: 5.0.8, 4.0.33, 6.0.0
Reporter: Scott Murphy Heiberg
{code:groovy}
@groovy.transform.CompileStatic
trait T {
String getName() { 'T' }
String m() { Closure<String> c = { -> this.getName() }; c() }
}
class C implements T {
String getName() { 'C' }
}
assert new C().m() == 'C'
{code}
Actual: under static compilation, {{ClassCastException: class java.lang.Class
cannot be cast to class T$Trait$Helper}}. A native lambda, a lambda typed
Closure, or a lambda inside a closure fails the same way. Dynamic Groovy and
@TypeChecked return 'T' instead of 'C': the call goes to the helper's static
method with a null self, so the implementing class's override is skipped. With
arguments it throws MissingMethodException; for a super-trait method it throws
NoSuchElementException. In a static trait method, {{this.getSimpleName()}}
inside a closure returns 'Helper' instead of 'C'.
Expected: 'C'. An explicit {{this.m()}} in a closure targets the implementing
instance, as a bare {{this}} in a trait closure already does, and as
{{this.m()}} in a closure of a plain class does (never the delegate).
Cause: TraitReceiverTransformer keeps the original {{this}} receiver for every
method call on this inside a closure. That is right for implicit-this calls,
which go through the closure's resolve strategy. For an explicit this.m() the
receiver ends up as the helper class, because the trait method body lives in a
static helper method.
Seen in 4.0.33, 5.0.8 and 6.0.0.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
