[
https://issues.apache.org/jira/browse/GROOVY-12533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135554#comment-18135554
]
Paul King commented on GROOVY-12533:
------------------------------------
spotted this late:
GROOVY-12533: silent @CompileStatic behaviour change.
- In an inner class Sub extends Outer, this.f for a private Outer.f used to
read the enclosing instance. It now reads the Sub instance.
- I checked: CS gives [changed, changed] before and [enclosing, enclosing]
after, wd, enclosing] throughout. So this.f now disagrees with dynamic code,
where beforethis.@f did.
- The property form isn't mentioned or tested. It also adds a new public
StaticCompsformClass().
> 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)
