[
https://issues.apache.org/jira/browse/GROOVY-12576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135509#comment-18135509
]
ASF GitHub Bot commented on GROOVY-12576:
-----------------------------------------
codeconsole commented on PR #3102:
URL: https://github.com/apache/groovy/pull/3102#issuecomment-6536950038
@paulk-asert Thanks.
1. **TO_SELF:** fixed in 63ca12a81d. The Object methods stay in the closure
lookup for `TO_SELF`, and SC calls them on the closure, so your example
compiles and returns the closure's `toString()` under SC and TC, as dynamic
does. `DELEGATE_ONLY` and `OWNER_ONLY` already matched dynamic (`'d'` and
`'C'`). The same commit fixes nested closures: with an owner-first strategy
dynamic calls the owner closure's own method, while the PR went on out to the
class or the outer delegate, and a closure nested in a `TO_SELF` closure even
threw a `ClassCastException`. Covered by
`testClosureObjectMethodResolveStrategy` (TC and SC).
2. **4.0 claim:** you're right. The description now has your table, says
this lines SC up with 6.0+ dynamic behaviour (GROOVY-11858), and recommends
backporting to 6.0.x, not 5.1.x.
3. **rehydrate:** done in e01034c17f. The writer tries `getOwner()` before
the closure, so `rehydrate(null, owner, null)` calls the owner's method.
Covered by `testClosureObjectMethodWithoutThisObject` and the updated
`testObjectMethodsInClosureWithoutThisObject`. After `dehydrate()` there is no
owner either; SC calls the closure's own method there, where dynamic calls it
on `null` (the description says so).
Also merged master (8d1b545714); it conflicted with GROOVY-12574 in
`StaticInvocationWriter`, and both changes are kept.
`MethodReferenceTest.testMethodReferencesInStaticAndDefaultMethodsOfInterface`
fails on master itself since #3056; #3116 fixes it.
> SC: toString(), hashCode(), equals() and getClass() in a closure ignore the
> delegate and the owner
> --------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12576
> URL: https://issues.apache.org/jira/browse/GROOVY-12576
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
> Affects Versions: 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Assignee: Daniel Sun
> Priority: Major
>
> Under {{@CompileStatic}}, an implicit-this call to a method of {{Object}} in
> a closure or lambda is made on the closure itself:
> {code:groovy}
> @groovy.transform.CompileStatic
> class C {
> String m() { new StringBuilder().with { append('w'); toString() } }
> }
> assert new C().m() == 'w' // C$_m_closure1@1b2c3d4
> {code}
> 4.0.33 returns {{'w'}}. The type checker looks up the methods of {{Closure}}
> before the delegate and the owner, and that lookup also returns the methods
> {{Closure}} inherits from {{Object}}. With {{with}}, {{tap}}, {{identity}} or
> a {{@DelegatesTo(strategy = DELEGATE_FIRST)}} method this ignores the
> delegate; in a plain closure it ignores the owner, and in a lambda the
> enclosing instance, which Java and dynamic Groovy both use. This happens in
> methods, constructors, field initializers and static initializers.
> Dynamic Groovy tries the closure first only for methods that {{Closure}} or
> {{GroovyObject}} declare; a method the closure inherits from elsewhere goes
> to the delegate or the owner according to the resolve strategy. Expected: the
> same under static compilation. Methods declared by {{Closure}}, such as
> {{getDelegate()}}, still resolve against the closure, and a closure without a
> this object (from {{dehydrate()}}) uses its own method.
> PR: https://github.com/apache/groovy/pull/3102
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
