RFR: 8338981: Access to private classes should be permitted inside the permits clause of the enclosing top-level class [v17]

[Vicente Romero]

On Sat, 19 Oct 2024 11:57:08 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix involves adding new flag to after context that indicates that currently resolved symbol is in permits clause
>
> Evemose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into selaed-permits-allow-private-members
>  - remove logging error
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - Revert bugid change
>  - Change bugid
>  - report feature error
>  - add feature
>  - make method names shorter
>  - fix test failures 3
>  - fix test failures 2
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/f514b97c...38dd1b5a

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 90:

> 88:             """
> 89:             public sealed class T permits S.A {
> 90:                 private static final class A {}

I don't see the need for class T.A in this test case. I think that you can get the same effect with:


class S {
    private static final class A {}
}

sealed class T permits S.A {
} 

having both classes in the same file, at least the error message is the same

test/langtools/tools/javac/sealed/PrivateMembersInPermitClause.java line 159:

> 157:      */
> 158:     @Test
> 159:     public void referencePrivateClassFails() throws Exception {

this one is very similar to: `otherTopLevelPrivateClassFails` I think you should keep only one of them

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1815692389
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1815695878