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

[Jan Lahoda]

On Mon, 26 Aug 2024 22:07:33 GMT, Evemose <duke at openjdk.org> wrote:

>> Fix is quite hacky, but this is best solution that i came up with without making invasive changes in other parts of jdk. Basically, I check if current symbol is symbol for tree inside of permits clause i na following way:
>> 
>> 1. env.tree is JCTree.JCClassDecl;
>> 2. Trees in extends and implements clauses are already not null
>> 3. There is at least one tree with null sym in permits clause (main indicator that permits clause resolution is in process)
>> 
>> If all three of above are true, the requirment for symbol to be visible is to have sym.owner.outermostClass() == env.tree.sym.outermostClass()
>> 
>> Not sure if this is a correct way to do it, hope more expirienced people out here could look into it more carefully.
>> 
>> DEV NOTE: Will add test a bit later
>> 
>> DEV NOTE 2: I`m not sure if non immidiate private memebrs should also be available in permit clause (like private static class A in private static class B that is in sealed class C should be available in permits clause of C as well). If not, condition on owner of symbol should be tightened a bit
>
> Evemose has updated the pull request incrementally with one additional commit since the last revision:
> 
>   allowed non-direct members to be permitted

Others may have a different opinion, but this seems a bit too hacky to me (given we would need to maintain this for a long time).

I would suggest to try to add a new flag into `AttrContext`, along the lines of `permitPrivateAccessInHeader`, and set it while attributing the permitted types. Not sure how invasive that'd be, but hopefully not terribly much. And it should be clear (and documented) what's happening.

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

PR Comment: https://git.openjdk.org/jdk/pull/20718#issuecomment-2311992230