Expand private members if necessary #517
Conversation
Verified that all tests still run. This is a first step, so that we can later on eliminate NotJavaPrivate altogether.
Resets private flag, and expands the name if necessary.
Logic moved from RefChecks to Mixin; implementation is now by name expansion instead of setting NotJavaPrivate flag.
A late miniphase which resets private flag of all members that are not accessed from within same class. Replaces logic in RefChecks. Doing this late has two advantages - we can use name expansion, because references are symbolic, so the names of symbols and references to them do not need to correspond anymore. - we can automatically correct for symbols moved in earlier phases (e.g. lifted out by LambdaLift).
It is now redundant.
|
Would we be able to use the same mechanism to allow macro expansions to access private members visible at the macro definition site? |
| * | ||
| * private def m(ps) = e | ||
| * | ||
| * --> private static def($this: C, ps) = [this -> $this] e |
There was a problem hiding this comment.
This description was copy-pasted from PrivateToStatic and does not match what this phase does.
|
You mean, make give private members accessed by a non-private macro expanded names? Yes that could work. |
|
@xeno-by I guess it would work only if macro expansion happens in same compilation unit where private member is defined. |
How does this play with separate compilation? If you have a implementation class, that overrides a private field but is separately compiled, will you try to retroactively mangle field defined in super class? |
|
After following the code I do not see how it will trigger problems. |
|
@odersky, there are other private methods that need to be |
|
Last fix allows dotty to pass flag verification of JVM. |
|
Ok, I'm preparing a fix. |
|
It seems there's more wrong with superaccessors than this. You need to fix On Sun, May 3, 2015 at 7:58 PM, Dmitry Petrashko [email protected]
Martin Odersky |
|
@odersky please review last 3 commits. |
|
LGTM. I had the same as your first commit, but got errors that were solved by your third commit. I am still puzzled why the scalac SuperAccessors explicitly defines symbols that are both Deferred and Private. I am also puzzled where super accessors for non traits (which are now private, but not deferred) actually get defined. But we'll figure that out, eventually. |
Expand private members if necessary
|
I figured it out. resolveSuper does the right thing for private super accessors. I'll add a test. |
|
@odersky, I have non-commited post-condition for super-accessors that checks that private super-accessors have non-empty rhs. I'll make a PR. |
Private members that are accessed from out of class, or that are overridden by implementation classes get mangled names and their Private flag is reset. NotJavaPrivate is eliminated.
Review by @DarkDimius