Scott Murphy Heiberg created GROOVY-12533:
---------------------------------------------
Summary: this.@name and super.@name fail in a closure of a nested
subclass for a private field of the outer class
Key: GROOVY-12533
URL: https://issues.apache.org/jira/browse/GROOVY-12533
Project: Groovy
Issue Type: Bug
Components: Static compilation, groovy-runtime
Affects Versions: 6.0.0
Reporter: Scott Murphy Heiberg
In a static nested class that extends its outer class, {{this.@f}} and
{{super.@f}} read a private field {{f}} of the outer class. Inside a closure or
lambda of the same method, both fail at run time:
{code:groovy}
class Outer {
private String f = 'outer'
static class Sub extends Outer {
def direct() { [this.@f, super.@f] }
def viaClosure() { [{ -> this.@f }(), { -> super.@f }()] }
}
}
def sub = new Outer.Sub()
assert sub.direct() == ['outer', 'outer']
sub.viaClosure() // MissingFieldException: No such field: f for class: Outer$Sub
{code}
{{super.@f}} in the closure fails the same way, with "No such field: f for
class: Outer". {{@TypeChecked}} behaves like dynamic Groovy, and both fail the
same way in a lambda, and for {{Sub.this.@f}} in an anonymous inner class
created in {{Sub}}. Under {{@CompileStatic}}, {{super.@f}} in a closure or
lambda throws the same {{MissingFieldException}}. {{this.@f}} fails there with
{{VerifyError}}, inside and outside a closure, until the change for
GROOVY-12511, which makes it read the field. Seen in 5.0.8, 6.0.0 and master;
in 4.0.33 the access failed outside a closure too.
Expected: the closure reads the field, as its enclosing method does.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
