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

Vicente Romero vromero at openjdk.org
Fri Oct 18 15:42:38 UTC 2024


On Sat, 12 Oct 2024 14:24:29 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 incrementally with three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/selaed-permits-allow-private-members' into selaed-permits-allow-private-members
>  - report feature error
>  - add feature

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 471:

> 469:                 return true;
> 470:             } else {
> 471:                 log.error(env.tree.pos(), Errors.PrivateMembersInPermitsClause);

we don't issue a compiler error while checking if a symbol is accessible or not, it should be the caller's responsibility to decide if a compiler error should be issued or not as it is done in other cases

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 475:

> 473:             }
> 474:         }
> 475:         return false;

shouldn't we return true here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1806699145
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1806699538


More information about the compiler-dev mailing list