[ 
https://issues.apache.org/jira/browse/GROOVY-12621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18142141#comment-18142141
 ] 

ASF GitHub Bot commented on GROOVY-12621:
-----------------------------------------

codeconsole commented on PR #3147:
URL: https://github.com/apache/groovy/pull/3147#issuecomment-6773200295

   @daniellansun On the land order: I answered this on #3137 
(https://github.com/apache/groovy/pull/3137#issuecomment-6717091856). In short, 
@paulk-asert's preference on #3169 is path (1) for 6.0.x regardless: keep the 
run-time behaviour and have type checking report the access. That is #3137 and 
then this PR, which is stacked on it. So the order I'd suggest is #3137, then 
#3147, both on master for cherry-picking to GROOVY_6_0_X. If path (2) is taken 
for Groovy 7, the rule is narrowed or dropped on master then, as Paul describes 
on #3169.
   
   The run of these shapes against #3169 is in 
https://github.com/apache/groovy/pull/3137#issuecomment-6608403166: three of 
them still fail at run time under #3169 (a receiver that is not an instance of 
the calling class, a write through `super` in a non-static inner subclass, and 
an enum constant body), so those rejections would stay under (2) as well. The 
`E.this` compile error for an enum constant body is independent of the 
direction.
   




> STC still accepts some private superclass field accesses under @TypeChecked 
> that fail at run time
> -------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-12621
>                 URL: https://issues.apache.org/jira/browse/GROOVY-12621
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 4.0.33, 5.0.8, 6.0.0
>            Reporter: Scott Murphy Heiberg
>            Priority: Major
>
> GROOVY-12610 makes the type checker reject property access to a private 
> instance field of a superclass when dynamic dispatch can never find it. Three 
> shapes are still accepted and fail with a MissingPropertyException.
> Enum constant body (z, this.z and super.z all fail):
> {code:groovy}
> @groovy.transform.TypeChecked
> enum E {
>     A { def n() { z } }
>     private String z = 'x'
> }
> E.A.n()
> {code}
> Write through super in a non-static inner subclass (compound assignment and 
> increment also fail):
> {code:groovy}
> @groovy.transform.TypeChecked
> class Base {
>     private String z = 'x'
>     class Sub extends Base {
>         def m() { super.z = 'y' }
>     }
>     def t() { new Sub().m() }
> }
> new Base().t()
> {code}
> Receiver that is not an instance of the calling inner class:
> {code:groovy}
> @groovy.transform.TypeChecked
> class Base {
>     private String z = 'x'
>     static class Sub extends Base {}
>     class Inner {
>         def m(Sub sub) { sub.z }
>     }
>     def t() { new Inner().m(new Sub()) }
> }
> new Base().t()
> {code}
> Actual: all three compile and then fail with MissingPropertyException: No 
> such property: z for class: E$1 (or Base$Sub).
> Expected: compile errors "No such property: z for class: ...", as for the 
> shapes GROOVY-12610 covers. Under @CompileStatic all three keep compiling, 
> since static compilation accesses the field directly.
> Cause: ClassNodeUtils.hasNoEnclosingInstance returned false for an enum 
> constant body, which is created in the enum's static initializer. The type 
> checker also did not take two run-time limits into account: there is no 
> enclosing-instance fallback for a write through super (GROOVY-11823), and the 
> fallback applies only when the receiver is an instance of the calling class.
> The enum case is seen in 4.0.33, 5.0.8 and 6.0.0.
> PR: https://github.com/apache/groovy/pull/3147



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to