[
https://issues.apache.org/jira/browse/GROOVY-12589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18135469#comment-18135469
]
ASF GitHub Bot commented on GROOVY-12589:
-----------------------------------------
codeconsole opened a new pull request, #3114:
URL: https://github.com/apache/groovy/pull/3114
**Stacked on #3049** (GROOVY-12518, which adds the `super$` helpers for
`super` property access in closures under `@CompileStatic`). Only the last
commit is this change; the rest is #3049.
Within a class nested in its superclass, `super.name` under `@CompileStatic`
called the wrong accessor or failed:
```groovy
import groovy.transform.CompileStatic
class Base {
boolean f
boolean isF() { true }
boolean getF() { false }
@CompileStatic
static class Sub extends Base {
boolean isF() { false }
boolean getF() { true }
def plain() { super.f }
def test() { def c = { -> super.f }; c() }
}
}
new Base.Sub().test() // MissingPropertyException: No such property: f for
class: Base$Sub
```
Dynamic Groovy calls `Base.isF`. On master both methods throw; with #3049
the plain `super.f` works and the closure and lambda forms still throw. If
`Sub` overrides only `isF`, they called `Base.getF`. Any overridden getter
(`String getX()`) failed the same way, and `{ -> super.x = v }` threw
`VerifyError`.
The type checker found the field in the superclass, which is an enclosing
class here, so it resolved `super.name` as that field, recorded no accessor and
asked for no `super$` helper. The code generators always go through the
accessor for `super.name`; in a closure they found no helper and fell back to a
dynamic `getPropertyOnSuper`, which cannot reach the overridden accessors of a
statically compiled class. `StaticTypeCheckingVisitor.existsProperty` now
resolves `super.name` and `Outer.super.name` through the accessors of the
superclass even within the declaring class of the field, choosing `isName`
before `getName` for a boolean property as the code generators and dynamic
Groovy do, so a closure calls the accessor through the `super$` helper.
## Tests
`FieldsAndPropertiesSTCTest.testSuperPropertyInClassNestedInSuperclass`
fails without the change under static compilation
(`FieldsAndPropertiesStaticCompileTest`); it covers static nested and inner
subclasses, reads in plain code, closures, lambdas and nested closures,
generated and overridden accessors, and writes and compound assignments in
closures. `testSuperBooleanPropertyWithIsserAndGetter` covers the accessor
choice for a plain subclass. The `groovy.transform.stc`,
`org.codehaus.groovy.classgen.asm.sc`, `org.codehaus.groovy.transform.sc`,
`gls` and `org.codehaus.groovy.transform.traitx` packages and
`groovy.ThisAndSuperTest` pass. The Checkstyle and CodeNarc gates pass.
Seen in 4.0.33, 5.0.8 and 6.0.0.
> SC: super.name within a class nested in its superclass calls the wrong
> accessor or throws MissingPropertyException
> ------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12589
> URL: https://issues.apache.org/jira/browse/GROOVY-12589
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> import groovy.transform.*
> class Base {
> boolean f
> boolean isF() { true }
> boolean getF() { false }
> @CompileStatic
> static class Sub extends Base {
> boolean isF() { false }
> boolean getF() { true }
> def plain() { super.f }
> def test() { def c = { -> super.f }; c() }
> }
> }
> assert new Base.Sub().plain()
> assert new Base.Sub().test()
> {code}
> Actual: groovy.lang.MissingPropertyException: No such property: f for class:
> Base$Sub, for both methods. If Sub overrides only isF, both return the result
> of Base.getF instead. The same happens for any property whose getter Sub
> overrides (for example String x with getX), and assigning super.x in a
> closure throws VerifyError.
> Expected: both assertions pass. Base.isF is called, as in dynamic Groovy.
> Within a class nested in its superclass, the type checker resolves super.f as
> the superclass field that the nested class may access, so it records no
> accessor and requests no super$ helper, and static compilation falls back to
> a dynamic getPropertyOnSuper call. That call cannot reach the overridden
> accessors of a statically compiled class, which has no MOP methods. A plain
> subclass that is not nested in its superclass is not affected.
> Seen in 4.0.33, 5.0.8, 6.0.0 and master. With PR #3049 (GROOVY-12518) the
> plain super.f works and only the closure and lambda forms fail.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
