[
https://issues.apache.org/jira/browse/GROOVY-12509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132524#comment-18132524
]
ASF GitHub Bot commented on GROOVY-12509:
-----------------------------------------
codeconsole commented on PR #3044:
URL: https://github.com/apache/groovy/pull/3044#issuecomment-6421024410
I've cut this down to the first step: the 6.0.0 regression for fields of a
private nested type (GROOVY-12310). The rest follows one pull request at a
time, each opened after the previous one is merged:
1. GROOVY-12512: calling an outer instance method where there is no
enclosing instance is a compile error. This only rejects code that already
fails at run time in every mode.
2. GROOVY-12509: private getters and setters of another class of the same
nest, through property syntax.
3. GROOVY-12510: a private method of a superclass is not found through a
subclass. Code that runs under `@CompileStatic` today stops compiling, as javac
rejects it.
4. GROOVY-12509: private methods and constructors of another class of the
same nest.
5. GROOVY-12511: `@CompileStatic` uses the enclosing instance for a private
member of an outer class that a nested class extends.
6. GROOVY-12513: private fields and accessors through a variable that flow
typing narrows to a subclass.
Each description lists the code that stops compiling and anything that
behaves differently under `@CompileStatic`. #3049 and #3050 are drafts until
the steps they need are merged.
> STC: private members of another class of the same nest are not accessible
> -------------------------------------------------------------------------
>
> Key: GROOVY-12509
> URL: https://issues.apache.org/jira/browse/GROOVY-12509
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
> Affects Versions: 6.0.0
> Reporter: Scott Murphy Heiberg
> Priority: Major
>
> Under static type checking, a class nested in a top-level class cannot use
> the private constructors, methods and accessors of another class nested in
> the same top-level class:
> {code:groovy}
> @groovy.transform.CompileStatic
> class C {
> static class Box {
> private Box(String s) {}
> private static String sm() { 'sm' }
> private String im() { 'im' }
> private String getX() { 'x' }
> }
> static class A { private static class Hidden { public static int x = 1 } }
> static class Other {
> static test(Box box) {
> new Box('a') // Cannot find matching constructor
> C$Box(java.lang.String)
> Box.sm() // Cannot find matching method java.lang.Class#sm()
> or static method C$Box#sm()
> box.im() // Cannot find matching method C$Box#im()
> box.x // No such property: x for class: C$Box
> A.Hidden.x // Cannot access field: x of class: C$A$Hidden from
> class: C$Other
> }
> }
> }
> {code}
> Java allows all of these (JLS 6.6.1: a private member is accessible anywhere
> within the body of the top-level class that encloses its declaration), and
> the JVM does through nestmates. Groovy already writes the {{NestHost}} and
> {{NestMembers}} attributes for these classes, the class generator already
> calls private members of nestmates directly, and the type checker already
> allows private fields of nestmates (GROOVY-12290). Method references such as
> {{Box::new}} and {{Box::sm}} are rejected the same way.
> The modes also disagree. With a private {{Box(String)}} beside a public
> {{Box(Object)}}, {{new Box('s')}} in {{Other}} calls the private constructor
> in dynamic and {{@TypeChecked}} code, as javac does, but the public one under
> {{@CompileStatic}}. The same happens for a private {{B.m(String)}} beside an
> inherited {{A.m(Object)}}.
> A private getter or setter used through property syntax ({{box.x}}) is also
> rejected from the outer class into a nested class.
> The last case, a public member reached through a private nested type
> ({{A.Hidden.x}}, or a constant of a private nested enum), worked in 5.0.8 and
> fails since 6.0.0 (GROOVY-12310), from a sibling and from the outer class.
> The other cases fail in 4.0, 5.0 and 6.0.
> PR: https://github.com/apache/groovy/pull/3044
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
