[
https://issues.apache.org/jira/browse/GROOVY-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135624#comment-18135624
]
ASF GitHub Bot commented on GROOVY-12612:
-----------------------------------------
codeconsole opened a new pull request, #3139:
URL: https://github.com/apache/groovy/pull/3139
An explicit `this.m()` inside a closure or lambda in a trait method does not
reach the implementing instance:
```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'
```
Under static compilation this throws `ClassCastException: class
java.lang.Class cannot be cast to class T$Trait$Helper`; lambdas fail the same
way. Dynamic Groovy and `@TypeChecked` call the helper's static `getName` with
a null self and return `'T'`. With arguments they throw
`MissingMethodException`, and for a super-trait method
`NoSuchElementException`. 4.0.33, 5.0.8 and 6.0.0 behave the same.
`TraitReceiverTransformer.transformMethodCallOnThis` kept the original
`this` receiver for every call inside a closure. That is needed for an implicit
`m()`, which must go through the closure's owner and delegate. An explicit
`this.m()` never goes through the delegate, in a trait or a plain class. It now
gets `$self` (or `$static$self`) as its receiver, as the call outside a closure
and a bare `this` inside a closure already do.
In a static trait method, `this.getSimpleName()` inside a closure now uses
the implementing class, not `T$Trait$Helper`, matching the same call outside
the closure. This composes with #3129 (GROOVY-12602), which fixes implicit-this
calls in lambdas.
## Tests
The new `testInvokeTraitMethodOnExplicitThisFromTraitClosure`,
`testInvokeTraitMethodOnExplicitThisFromTraitLambda`,
`testInvokeMethodOnExplicitThisFromStaticTraitMethodClosure` and
`testInvokeTraitMethodOnExplicitThisFromTraitClosureOrLambda` in
`TraitWithClosureOrLambda` fail without the change. Together they cover own and
super-trait methods, arguments, private and static methods, nested closures,
`with`, safe calls, a DELEGATE_FIRST closure, native lambdas and lambdas typed
Closure, in dynamic, `@TypeChecked` and `@CompileStatic` modes.
`org.codehaus.groovy.transform.traitx.*`, `groovy.transform.stc.*`,
`org.codehaus.groovy.classgen.asm.sc.*`, `groovy.ThisAndSuperTest`,
`gls.closures.*` and `TraitsSpecificationTest` pass. The Checkstyle and
CodeNarc gates pass.
> 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: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {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)
