-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #3339: Disallow accesses to private package members from nested pkgs #3735
Conversation
…ted pkgs Change of the accessibility rules: Disallow accesses to private package members from nested packages. Such accesses were causing an access error at runtime before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM but a test case is missing.
@@ -733,7 +730,9 @@ object SymDenotations { | |||
( !(this is Local) | |||
|| (owner is ImplClass) // allow private local accesses to impl class members | |||
|| isCorrectThisType(pre) | |||
) | |||
) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This long chain of conditions is getting really hard to read, factor it out into a few vals?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried but it does not seem to help. The key is treating !A || B as an implication, then things get clearer. I was wondering whether we should add an inline helper method implies
on Boolean
to do this. But it's quite a lot of effort.
Test case is i3339. In ``` package outer { private class A() { override def toString = "A" } package inner { object Test { def main(args: Array[String]): Unit = { println(new A()) // allow access? } } } } ``` should the access to private class `A` from a nested package be allowed? The usual rules for Scala say yes, since the access is from a nested scope. We changed this to in scala#3735 to "no", since we wanted to emulate Java's default package-private visibility. But this is unsystematic for two reasons: - it breaks the universal meaning of `private` in Scala - it uses a different name (i.e. private) for what is not named in Java at all, and is named `internal` in Kotlin. - it does not generalize to members of classes which could also profit from a Java-package-private visibility specifier. I believe it is better to leave `private` as it is, and, if we want to emulate `internal` (which might be a good idea), introduce a new modifier for it.
Test case is i3339. In ``` package outer { private class A() { override def toString = "A" } package inner { object Test { def main(args: Array[String]): Unit = { println(new A()) // allow access? } } } } ``` should the access to private class `A` from a nested package be allowed? The usual rules for Scala say yes, since the access is from a nested scope. We changed this to in scala#3735 to "no", since we wanted to emulate Java's default package-private visibility. But this is unsystematic for two reasons: - it breaks the universal meaning of `private` in Scala - it uses a different name (i.e. private) for what is not named in Java at all, and is named `internal` in Kotlin. - it does not generalize to members of classes which could also profit from a Java-package-private visibility specifier. I believe it is better to leave `private` as it is, and, if we want to emulate `internal` (which might be a good idea), introduce a new modifier for it.
Change of the accessibility rules: Disallow accesses to private package members from nested packages.
Such accesses were causing an access error at runtime before.