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