Scott Murphy Heiberg created GROOVY-12576:
---------------------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
