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

[Evemose]

On Fri, 18 Oct 2024 15:39:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> 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

thanks for the note, will keep in mind from now on

> 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?

No, method name is privateMemberInPermitsClause if allowed, and return is:
1. If condition in if is met, then return whether feature is enabled or not (value of field allowPrivateMembersInPermitsClause)
2. If condition is not met, then this is NOT privateMemberInPermitsClause, so return false

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1807042268
PR Review Comment: https://git.openjdk.org/jdk/pull/20718#discussion_r1807044737