[
https://issues.apache.org/jira/browse/GROOVY-12610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136986#comment-18136986
]
ASF GitHub Bot commented on GROOVY-12610:
-----------------------------------------
paulk-asert opened a new pull request, #3169:
URL: https://github.com/apache/groovy/pull/3169
… dynamically
Statically compiled code accesses a private field or method of a superclass
directly from a subclass nested with it, but dynamically dispatched code (and
so @TypeChecked code) failed at run time: the metaclass view of a subclass does
not list private members of its superclasses.
When the caller's view has no such member, MetaClassImpl now looks for a
private field or method in a superclass of the receiver's class, provided that:
- the caller (for a closure, its enclosing class) is a subclass of the
declaring class and the receiver is an instance of the caller; a private member
is not inherited, so a nest-mate outside the hierarchy does not reach it
through a subclass instance (GROOVY-10198);
- the caller and the declaring class are nest-mates;
- the caller is not an inner class whose chain of enclosing instances leads
to the declaring class, which instead resolves to the enclosing instance
(GROOVY-12533).
Fields: in getMetaProperty, which covers property get/set, attribute (.@)
access and super access. A subclass's own getter still wins; the field now
takes precedence over propertyMissing, as under static compilation.
Methods: in invokeMethod for a super call or a sender other than the
receiver's class; in Selector.chooseMeta with the real caller (the selection
base stands in the receiver's class); and in ClosureMetaClass for delegation
from a closure of the declaring subclass. The sender-less invokeMethod(Object,
String, Object[]) names the receiver's class as sender and cannot vouch for the
caller, so it does not consult the fallback. It still dispatches through the
overridable six-argument method, which ExpandoMetaClass relies on.
A per-metaclass flag records whether any superclass shares a nest with a
class below it, so the miss path (methodMissing, propertyMissing, builders)
costs a field read.
Known gap: the sender-less property entry points (getProperty(Object,
String), getAttribute(Object, String), InvokerHelper.getProperty) also name the
receiver's class as sender, so a caller outside the nest can reach such a field
through them. Closing that needs the caller carried through the MOP (see
GEP-31).
Spike only: no tests added yet; the selected suites pass (groovy.lang,
o.c.g.runtime, STC/SC, gls, bugs, groovy.util, o.c.g.transform, vmplugin).
> STC accepts access to a private superclass field through a nested subclass
> under @TypeChecked, which fails at run time
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12610
> URL: https://issues.apache.org/jira/browse/GROOVY-12610
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.33, 5.0.8, 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> {code:groovy}
> class Base {
> private String z = 'x'
> @groovy.transform.TypeChecked
> static class Sub extends Base {
> def m() { this.z } // also: z, super.z, closures, lambdas, writes,
> that.z
> }
> }
> new Base.Sub().m()
> {code}
> Actual: the code compiles, then fails with MissingPropertyException: No such
> property: z for class: Base$Sub. Dynamic Groovy fails the same way.
> Expected: under @TypeChecked, a compile error "No such property: z for class:
> Base$Sub", as already reported when Base and Sub are both nested in another
> class. @CompileStatic keeps accepting the code, because it accesses the field
> directly from a nest-mate.
> Cause: the type checker uses the nest-mate accessibility rule of static
> compilation for @TypeChecked code too. Type-checked code is dispatched
> dynamically, and the metaclass of a subclass does not list a private field of
> its superclass.
> Seen in 4.0.33, 5.0.8 and 6.0.0.
> PR: https://github.com/apache/groovy/pull/3137
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
