[
https://issues.apache.org/jira/browse/GROOVY-12533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun reassigned GROOVY-12533:
-----------------------------------
Assignee: Daniel Sun
> 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: groovy-runtime, Static compilation
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Assignee: Daniel Sun
> Priority: Major
>
> 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)
